This is the forum archive of Homey. For more information about Homey, visit the Official Homey website.
The Homey Community has been moved to https://community.athom.com.
This forum is now read-only for archive purposes.
The Homey Community has been moved to https://community.athom.com.
This forum is now read-only for archive purposes.
Comments
Although I observed more crashes / failing motion sensor with an interval of 300 seconds or lower compared to the current 900... Which corresponds to @Ziglar's observations
in the meanwhile, 2 days, 2 homey crashes (led ring is luminated, but does not flow, no connection to homey)
this kind of tells me that the zwave of homey is not yet stable as i have hoped so.
maybe the @Athom team can check this ?
Temperature and illumination reports are not becomming visible in Insights (motion still is):
And under settings; the motion sensor shows "(failed)":
Note: I do not have similar issues with the Powernodes connected to Homey...
A restart of the Z-wave chip typically solves this issue.
LOG id: 3C65B47F43 (after Z-wave restart)
Does anyone have similar experiences? @Taco any advice?
It works, only not when temp or illum changes, but when the hourly update is made:
Based on some remarks of Robinyoh on Github #492 and @Caseda that parameter 6 has an offset of around 258-268x... I started to test the hypothesis that this also affects other (2-byte size) parameters... and it does (at least on 0.8.32)!
I tested several values of parameter 42 and 64 on my 2 motion sensors today... ranging from 1 up to 30.
All (2 byte size) values appear to have an offset of around 255x.
So setting parameter 42 (illumination report interval) to 3 will result in an illumination report every 773 seconds (257x).. every 13 minutes.
This also explains that parameter 40 (illumination threshold value; for an sensor positioned in a shady area) as well as changing the wakeup interval appears to have no effect. Setting parameter 40 to a value of 2 Lux.. would mean that with the same factor, only changes in illumination of > 510 Lux will be reported (which is not the case for a indoor sensor positioned in a shady corner)...
So my 'issue' on getting a more frequent illumination report is contained by setting parameter 42 to 42,2,3
See Github #464 Homey not able to receive (multi) sensor data, only with polling or wakeup and #492 Fibaro motion sensor firmware 2.7 -> alarm wont go off for more details.
Open questions:
1) Applicable only of 0.8.32 or also below?
2) Similar issue on v3.2 Fibaro motion sensors (expected, but I cannot confirm)
3) also applicable to other Fibaro devices?
4) Reproduce setting 40 (illumination threshold) with an outside motion sensor
If other people have the possibility to check above open questions, please contribute the results to Github #464 Homey not able to receive (multi) sensor data, only with polling or wakeup
@Caseda can you add this to [How-To] Z-Wave Devices?
I have added (changed) this in the z-wave topic
ok so how is it responding in the past 24 hours ?
could u share the complete entry ?
To further understand the issue, I'm running some tests today..
The settings I currently use:
40,2,2;42,2,3;64,2,1800;80,1,0;89,1,0
40 (illumination threshold) doesn't do anything due to indoor usage (explained above)
42 (illumination reporting interval) provides an report every 12 minutes
64 (temperature reporting interval) provides an report every 34 minutes
80 disable led on motion trigger
89 disable tamper alarm
Z-wave stability is (unfortunately) not impacted by these parameter changes... I'm still having network crashes... As suggested by @BasVanDenBosch I will do a full reset possibly this evening to see if this is improving the Z-wave stability.
Please mind that I changed the values of the 2nd (light green) sensor 3 times (8:20, 10:45 and 14:00), including reboots. As of 14:00 also the 2nd sensor reported based on the 42,2,3 setting every 12 minutes.
On the actual issue, it turns out that it is most-likely caused by a byte transformation issue... see Github #464 Homey not able to receive (multi) sensor data, only with polling or wakeup
results:
In the meantime, @Taco confirmed the cause of the issue with 2 and 4 byte size parameters::
According to the statements made on Slack regarding the release of 0.8.33 on May 6th:
40,2,1;42,2,11265 (byte flipped -> 5 minutes or 300 seconds)
It only worked from 01:00 on, maybe this is a sensor thing?
this is until 18:00.
but since there are too many updates (301!) i added up all the timings:
and the reason for the higher "second" counts is probably because the lux had no difference in them
even though i put in parameter 40 (lux threshold), i don't think it did anything because even differences in 1 lux were registered.
PS: the big rise is me opening my curtains.
so basicly value 42 is now " 42,2,3 " and after the update we should be able to set it to for example 300 seconds " 42,1,300 " ?
chart from yesterday:
If you already want to have the 5 minute interval before 0.8.33 is released, you can apply the settings @Caseda mentioned above: 42,2,11265 (byte flipped version of 300).
see the github issue for other set points / way to calculate these set points.
- I have already rest z-wave network (and re-boot) homey
- Factory-defaults loaded in sensor (pressing long-time B till yellow, then pressed ones til red-blinks)
- Add new z-wave device in associate 3
Now I cannot change (add) any of the settings/parameters of my device (FGMS-001 EU V2.7)
I'm having exact the same problem adding a new out-of-the-box V2.7 sensor the the network. Pairing is okay, but afterward changing any of the properties results in the same error.
Someone already figured out how to circumvent this problem?
Don't know what's happening with the battery
Going to set it to 600 (setting with new firmware) now, see what will happen the next hours.
Look into parameter 62.
By default the sensor only measures the temperature every 900 seconds or 15 minutes.
If you want a report faster then this 900 seconds you will need to change this parameter accordingly.
So with 62 @1800 seconds the temperature will never change for half an hour because it is not being measured in between.
ìs that a known working solution in this case?. It doesn't work in my case (at least the configuration parameters are not reflected in the device settings afterwards)
Set my Fibaro motion sensors to the following parameters:
40,2,10 Report illumination based on a change of 10 Lux
42,2,300 Report illumination every 300 seconds
64,2,900 Report temperature every 900 seconds
80,1,0 Disable LED during motion detection
89,1,0 Disable LED during tamper alarm
And the motion sensors are working (almost) as expected; specifically on parameter 40 and 42.
Most likely, I made an error (during the night) setting the yellow motion sensor to 40,2,1 instead of 40,2,10
Yes, it was late
I do have a nice icon now on the device status card... but no reporting in Insights (yet)...
Strange that the icon on the device status card is showing 100% and that no data point(s) is visible in Insights...
OT: It is running (stable) now for more than 10 hrs... Let's start with installing some KaKu...
the decrease will be so slow it almost won't show up (with difference) in insight.
I do like the small icon much better now for battery
For more background info: [How-To] Z-Wave Devices