Welcome to Smart Home Forum by FIBARO
as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.
As a member you can:
- Start new topics and reply to others
- Follow topics and users to get email updates
- Get your own profile page and make new friends
- Send personal messages
- ... and learn a lot about our system!
Smart Home Forum by FIBARO Team
Search the Community
Showing results for tags 'zw5'.
Found 6 results
I have a couple of Fibaro wallplugs that I'm having problems with. Symptom is: Sometimes, when I turn the plug on the will automatically turn off again. Same thing goes other way around. If i turn them off they will automatically be turned on again. This happens like 1 time out of 10. Wallplug will come out of sync with any GUI (mobile app or web gui) which will display wrong state. On when its really off and the other way around. If I keep toggling the state when this happens the plug will soon be marked as "dead node". Removing the plug from the socket and replacing it again will get it back in sync. All wallplugs I'm having problem with are the newer ZW5 ones. I have handful of older plugs and never had any problems with them that I know of. What I have tried: * Removed and re-added them from network several times. In secure mode and not. * Fibaro support suggested to replace the plug. I returned it to the store and got a new one. Might be that I just got another one from a "bad batch"? * Moved the plug around in the house. Sometimes really close to the HC2. * Different devices connected. Haven't heard from Fibaro support after I replied that replacing the plug with a new one didn't help. That was over a month ago. I sent a reminder yesterday. Fibaro case #89048. /Alex
According to the FGK-10x ZW5 Operating Manual : 52. Interval of temperature reports This parameter determines how often the temperature reports will be sent to the main controller Reading that, I assumed that even with a 100% stable temperature, a temperature report would be sent to the Hub every xxx seconds, as specified into this parameter. I set xxx to 14400 seconds = 4 hours, but the Events List shows that I can wait for as long as 6 hours and more before getting such a Multi Level Sensor Report. And this is not the case of some of the reports being accidentally lost, because I have observed multiple instances of this problem. So my question is : do I read incorrectly what Parameter 52 means ? Or does it not work ?? Has anybody observed it actually working ???
I found a very curious bug with the ZW5 version (version >=3.2) of the FGK-101+DS18B20 temperature sensor. When explicitly requiring a temperature report [thru "Sensor Multilevel Get" -> "Sensor Multilevel Report" commands], the actual temperature value reported via the ++synchronous++ Sensor Multilevel Report answer is buggy : +/- 0.5 to +/- 1°C random error from the correct temperature value; the variable size of the error is similar to what you would expect using only 8 bits of resolution from the DS18B20 measures. But when the FGK-101 itself sends an ++asynchronous++ report, after setting parameter#51 "Temperature reports threshold" to 3/10 °C and parameter#52 "Interval of temperature reports" to 4hours, then the temperature reported by the SAME Sensor Multilevel Report() from the SAME FGK-101+DS18B20 is correct !?. Note that parameter#50 "Interval of temperature measurements" is set to 60 seconds, which precludes such large variations in so little time; I also tried setting it to 5 seconds, no difference. I found this problem while developing a FGK-101\ZW5 handler for the SmartThings platform, but I would expect this bug to be present as well with the Fibaro Home Center 2... unless Fibaro uses some "hidden parameter" which corrects this bug. At that point, I have no idea how to correct this bug, except by removing from my handler all "Sensor Multilevel Get()" synchronous temperature requests, and relying only on asynchronous notifications. Interestingly, the correct asynchronous Sensor Multilevel Reports come CRC16-encoded, while the buggy synchronous ones come in clear. That suggests to me 2 different branches of code inside the FGK-101 firmware, but does not help me to workaround this extremely curious bug... And the same handler works fine with the older FGK-101 (version <=2.5). While I expect the same bug to exists when pairing the FGK-101\ZW5 to a Fibaro Home Center 2 controller, I would still be interested in getting a confirmation, which would definitely exclude the SmartThings hub from the list of suspects. Any help or suggestion greatly appreciated : this has been driving me crazy for days !
Does anybody know the ACTUAL resolution programmed into the DS18B20 chip when inserted into the ++ZW5++ version of the FGK-101 ? The resolution of this chip is programmable at power-on to 9, 10, 11 or 12 bits, giving respectively 0.5, 0.25, 0.125, 0.0625°C increments. With the pre-ZW5 versions of the FGK-101, the resolution was clearly 12 bits, which happens to be the DS18B20 default resolution at power-on. But using the ++ZW5++ version of the FGK-101, with the SAME Device handler, I get DISCONTINUOUS readings, for instance 22.4, 22.8, 23.1, 23.4, 23.8°C, but NEVER values in between, such as 23.5, 23.6, 23.7°C for instance. This is consistent with a 0.25°C / 10 bits resolution only, which would be a major regression compared to the 12 bits of the pre-ZW5 FGK101+DS18B20. And AFAIK, there is no customizable parameter which would allow me to force 12 bits resolution back. Note that since all FGK-101 temperature parameters (51, 53, 55, 56) are given with 0.1°C quantum, only a 12 bits resolution is consistent with those parameters.
I am trying to develop a custom handler for an open Z-Wave platform which supports BOTH the old Z-Wave version of the Door/Window Sensor FGK-101 and also the newer Z-Wave+ version (aka ZW5) FGK-101. To do that, I need to reliably differentiate FROM WITHIN THE HANDLER the 2 versions. But there are multiple commands for getting Z-Wave / Device informations, and I just don't know what is the proper one to use and the proper attribute to check to ensure a 100% accurate and robust differentiation : ZWavePlus Info, Manufacturer Specific, Version, etc... Any help appreciated