qnstie

Od kilku lat mam HC2 z kilkudziesięcioma skonfugurowanymi urządzeniami. Przez te lata przeszedłem wiele update'ów centalki, z których kilka (szczególnie w II połowie 2018) było kłopotliwych i skutkowało dziwnymi problemami z urządzeniami, część z nim trzeba było usuwać i dodawać na nowo itp. Po którymś z ostatnich update w 2019 znów miałem problemy z paroma urządzeniami, które przestały reagować i przy okazji robienia porządku okazało się, że część ze skonfigurowanych urządzeń jest niemożliwa do usunięcia - ani "klasycznie" (przez wprowadzenie centraliki w tryb uczenia/kasowania i uruchomienie urządzenia), ani nawet za pomocą "Force delete". GUI Fibaro wprawdzie wyświetla komunikat, że urządzenie zostało usunięte, ale NIE znika ono z listy urządzeń, nawet po restarcie centralki. Można tak kasować je wielokrotnie, nic to nie daje. Na razie sobie radzę przez zaznaczenie ich jako "disabled" i "hidden", ale ewidentnie nie jest to sytuacji normalna. Nie mam również pewności, że te urządzenia nie psują jakoś sieci z-wave (np. przez próby ich pollingu przez sieć). Chętnie bym się ich pozbył, ale nie mam pomysłu jak, poza całkowitym resetem sieci, czego bardzo chcę uniknąć, bo mam bardzo dużo scen, które trzeba by rekonfigurować... Podejrzewam, że problemy z 2018 spowodowały jakieś niekonsystencje w bazie urządzeń w Fibaro, leci pewnie jakiś wyjątek w kodzie i w efekcie urządzenie nie jest usuwane. Jeśli to tylko problem kosmetyki, to mogę z tym żyć. Ale obawiam się "gnicia" systemu. Jakieś pomysły? Z góry dziękuję! Paweł

@cag014 I do not know if you have a similar problem, but I had a long-lasting issue with my wireless Popp Rain Meter, which becomes dead usually within 30 minutes from last manual wake. In the UI it manifests itself as a grey cross and a standard "communication problem" message. When I click it in the UI, it wakes up without any problems. But when I tried to wake it up periodically from the code using fibaro:wakeUpDeadDevice(ID) command, it never works. Perhaps you have a similar issue. I solved my problem replacing the above command with: api.post("/devices/"..v.."/action/wakeUpDeadDevice", {}); which works great (because it is exactly what the UI does, apparently the implementation of this service does something more than just calling the fibaro:wakeUpDeadDevice(ID)). Maybe it will be of some help. My full scene code is attached below (as you can see I have a predefined list of the devices that potentially need waking up, I do not query all of the devices). --[[ %% autostart %% properties %% globals --]] -- Code by qnstie, based on https://gist.github.com/leeroybrun/9482703#file-wakeup_dead_nodes-lua local devicesToWake = {1,2,3} local howOftenInMinutes = 10 function wakeupDeadNodes() for k,v in pairs(devicesToWake) do local status = fibaro:getValue(v, 'dead') if status == nil then fibaro:debug('Device '..v..' does not exist, please remove it from the list!') elseif status >= "1" then fibaro:debug('Device '..v..' is dead, waking it up') api.post("/devices/"..v.."/action/wakeUpDeadDevice", {}) -- THIS IS THE MOST IMPORTANT LINE -- fibaro:wakeUpDeadDevice(v) -- this does not work with e.g. Popp Rain Meter, hence the api call above fibaro:sleep(5000) --check again in 5 sec status = fibaro:getValue(v, 'dead'); if status >= "1" then fibaro:debug('Device '..v..' is REALLY DEAD') else fibaro:debug('Device '..v..' is now OK') end else fibaro:debug('Device '..v..' is alive, skipping') end end end local sourceTrigger = fibaro:getSourceTrigger(); if (sourceTrigger["type"] == "autostart") then while true do wakeupDeadNodes() fibaro:debug('Next check in '..howOftenInMinutes..' minutes.') fibaro:sleep(howOftenInMinutes*60000) end else local startSource = fibaro:getSourceTrigger(); if (startSource["type"] == "other") then wakeupDeadNodes() end end

@Sankotronic Absolutely awesome, thank you very much! I had no idea about the existence of the "api" object, I believe that there are not too many people who are aware about it (judging at the code shared on this forum or on Github). This alone resolves 90% of the serious problems with HC2 coding I encountered so far. BTW, this does not seem to be documented anywhere. Do you know if it is a feature that we can rely on (not something that will be removed at the next firmware update)? Thanks also for the hint with the labels to indicate the current values. While it is a space-consuming workaround, it makes a lot of sense. Also your solution to keep the variables in a table is very clever, while I would very much preferred to have "class" variables in a VD or scene (it would be much cleaner), keeping all the variables of a given VD or scene in one global (well named) variable is way cleaner than polluting the variables with multiple individual strings or numericals. Thank you again, you made my day. @Fibaro I still think that my original requests are viable but thanks to @Sankotronic they are all much less important to me now. Is there any documentation mentioning the "api" object (and maybe more "secret" goodies I am not aware about)? I cannot find it anywhere, not even on developer.fibaro.com (all the examples and descriptions there mention the actual webservice HTTP calls). Thanks in advance.

@gucio1234 Thanks for the examples, but: Ad. 2: The idea was to have the min, max and the current values DISPLAYED in the UI, so that the user would not guess what value he/she selected. For instance - if the slider was about setting the hours of delay, he/she would be able to move the finger until "12" is shown - not to guess that "12" is probably somewhere close to the middle of the slider... I admit I did not write that clear enough (it seemed obvious). Your solution is of course correct to set the value, but does not provide any feedback to the user who moves the slider. Ad. 3: The whole idea was NOT to use the webservice (the line with HC2 = Net.FHttp(...) ) because it is a dangerous workaround, which requires you to put in the code (in open text) the credentials of the superuser! Gee, how about the security of that solution (not mentioning how ugly and long the code is). Of course, for now it is the only way to achieve the auto-creation of the variables (and I use the same code in my VDs now, sadly). Thanks anyway and take care.

@I.Srodka Dziękuję za informację, rzeczywiście jest to jakieś tymczasowe obejście problemu. Niemniej jednak podtrzymuję, że to jest rozwiązanie złe: sztuczne dzielenie jednego konta (nawet jeśli tylko do dostępu zdalnego), to proszenie się o kłopoty, pomijam już jak niejasne to jest dla użytkowników. Bardzo proszę o dorzucenie tego do listy funkcjonalności do zaimplementowania. Pozdrawiam!

@gucio1234 Few lines of code, really? I wonder how. Would you mind sharing links to some examples?

Fajnie, że dostęp zdalny został zaimplementowany, ale to, że ma do niego dostęp tylko administrator to jakaś aberracja. U mnie spowodowało to to, że musiałem skonfigurować całej rodzinie aplikacje mobilne z dostępem administratora, bo inaczej nie mogliby otwierać bramy wjazdowej (gdzie nie ma domowego WiFi, m.in. ze względów bezpieczeństwa)... To by było tyle na temat bezpieczeństwa i uprawnień użytkownika wg Fibaro. Wg mnie to jest sprawa dość priorytetowa - admin powinien mieć możliwość definiowania które konta Fibaro Cloud mają mieć dostęp zdalny do HC2 i sprawa byłaby załatwiona, można by tym wtedy jakoś sensownie zarządzać. @Fibaro Nie wiem, czy to forum jest przez Was regularnie śledzone, ale IMO to jest istotna sprawa do wrzucenia do kolejki dla developerów (o ile już nad tym nie pracujecie, oczywiście). Pozdrawiam!

I have recently played with VD programming and I encountered a few problems in VD programming that I would be very happy to have addressed by Fibaro team in one of the next releases: 1. Please add variables to VD scope, shared across buttons and main loop It is now quite cumbersome to code VDs that have some (even very basic) state and logic. There now seem to be only the following options of keeping the state: - Create a global variable (most obvious, but problematic) - Keep data in the sliders (integers only, generally in range of 0-100) - Keep data in physical device parameters (if you happen to have one that allows it!) - Use external web service API Each of these has serious problems, probably quite obvious for everyone. How about adding a possibility to define within the VD a set of parameters, accessed - once defined - in the same way as the "IPAddress" and "TCPPort" are accessed, namely: fibaro:getValue(fibaro:getSelfId(), 'MyVDParameter') I do not think it would be a big problem for the Firabo team and would be a great help for the crowd developers. 2. Please add option to define a range for VD sliders. The sliders now always have range of 0-100. But this is not very useful for cases like I had with sprinkler control, where I wanted to give user a possibility to delay the sprinkler in range of 0-24 hours. Please add a possibility to define min, max and step values for the slider. 3. Please add an API function (or metadata) to CREATE a global variable, a "constructor" code block I know this may be tricky security-wise, but in order to automatically create global variables that are needed by the VDs or scenes, the developers are forced to do even more dangerous tricks (as using webservice API with open superadmin usernames and passwords). Therefore I ask - please add a method (e.g. fibaro:createGlobalVariable()) to allow developers creating global variables lege artis. It would be even better (especially security-wise), if you added (in VD and LUA scene) a special "constructor" block of code which is executed only once, during the first run of a scene or installation of a VD, where such methods could be used safely (because only super admin has rights to install/define a VD and scene). Thanks in advance!

@marecki_0luk1 Thanks! @T.Konopka Good idea, will do.

Hi, Here is my little contribution to the sprinkler control topic. The attached virtual device allows controlling the Sprinkler Panel parameters (so that you can define your own complex scenes tied to e.g. a Popp rain meter and any thermometer) and is compatible with the most recent Fibaro HC2 API (version 4.130). It is inspired by the Vesternet solution cited many times before, which unfortunately does not work anymore and causes HC2 restarts, probably because of the changes in the undocumented features of the API. Please take in consideration, that my solution also uses an undocumented API features (mainly: using PUT to change just the adjustWater and rainDelay parameters, as hinted by other users before - neither of these are documented in the api listed at http://[your.h2c.local.address]/docs ) and it may stop working in the future. But it works now Oh, the Fibaro API now REQUIRES the superadmin account (because of the PUT request). I always try to avoid that (instead using a dedicated "api" user with limited privileges), but in this case there does not seem any other way. You need to set the account in the code of the "Submit" button (clearly indicated). My VD is a bit more complex than in the Vesternet solution in order NOT to repeat the user/password sections (and reduce boilerplate code). Instead, I keep the values to submit to the panel in the sliders (that is why they are important, as is the "submit" button). A little bonus of this solution is that you can use the sliders to manually modify the adjustWater and rainDelay parameters if you like. Have fun! qnstie Sprinkler_control_qnstie.vfib

+1 from me, with some more details below. I now own a dedicated NorthQ power meter. It is a great (and quite cheap!) little device that is installed on top of an existing home power meter and which reads the wheel or a diode (depending on the meter type). This allows 100% synchronization of the reading with what I pay the utility company. It also works very well with Fibaro... to an extent. Unfortunately Fibaro does not allow incorporation of the total power into the energy panel (as stated in the original post in this thread). We need it! There is also a second huge problem with this particular device. It does not report the power consumption in the same way as other real-time devices do, but reports the cumulative power consumption every 15 minutes (which is very OK IMO). So - I get eg. 1000.00 kWh, then 15 minutes later - 1000.21 kHw etc. Because of the way Fibaro power panel works, these readings are useless there and cannot be visualized. The way people (myself included) deal with this problem now is using a special virtual device (e.g. created by jompa68). But this requires some advanced programming and general IT knowledge and is definitively not a solution for everyone.) I would be very happy if the great Fibaro team could take into account this case when updating the power panel. I believe that this kinds of meters will grow in popularity (especially with their low price already) and frankly I do not believe there is any other way to control the real total power consumption of the house than using a cumulative power meter - with an exception of smart houses built from the ground up, all other z-wave installations will have power monitoring limited to a subset of power-hungry devices anyway (I have probably 100-200 various electrical appliances in my small house and I do not see transferring them all to z-wave anytime soon due to the equipment and labor costs and logistics).

Not bad. Actually, this is another (home grown) approach to get something similar to what I described in my post: [Feature request] Push notification when HC/HC2 cannot be reached I however think it is much more useful if you get notification (a loud one, probably) if something is really NOT right.

@jakub.jezek, this is a good idea (even if limited, as Android 7.1 has now only 1.2% coverage), but I was asking for something much simpler. I wanted to have a folder in the Fibaro app with shortcuts to the functions (devices, scenes etc.) chosen by the user. Something like below (this is my quick and dirty visualization of what I imagine). The "shortcuts" folder is highlighted in yellow in the first screen, it would lead directly to the second screen.

I would like to request the following functionality (this applies probably mainly to the Fibaro Cloud, but should manifest itself mainly in a mobile app). The problem: AFAIK there is no way to be notified if the HC/HC2 is no longer available in the internet. And this is very important, because this can mean a number of bad things: 1. The power is down 2. The internet connection is lost 3. There is a burglary and someone disabled the system 4. Many more... The solution: Fibaro Cloud servers should be able to provide (probably upon request) a simple monitoring functionality of the HC/HC2 centrals (simple "is alive?" call, probably invoked by the HC/HC2). If the "is alives" are repeatedly not received (some simple rules decreasing the rate of false notifications couldapply), the user (administrator?) should get a push notification and optionally an email. Thanks in advance!

The problem: Some of the functions in Fibaro may get pretty security-sensitive, especially around locks and security systems. However, the security of the Fibaro App is not very convincing! 1. The app does not allow requesting any type of authorization when connecting to the system. 2. Some (if not all) sensitive functionalities (like a secure lock) cannot be additionally protected by the app. The solution: I would be very happy to see the following options (I stress: options, not user requirements, as many users do not need any security at all!): 1. Starting the app (= connecting to HC/HC2) should have an option to request a fingerprint authorization or a PIN. The fingerprints seem to be already implemented in the app, and they are very useful and fast, so why not use them? 2. The user (or maybe even the administrator) should be able to set additional authorization (again: fingerprint or PIN) on any chosen functions. The most important ones are the secure devices, but it probably also applies to scenes and maybe any device in general. Thanks in advance!