Zwave Fibaro Smoke sensor / state change during regular wakeup

@jaydee73, Thanks a lot. I think, after the issue is fixed it will also be in stable version 2.1.0. (in a few months)
How can I than switch “back” from a snapshot release to stable 2.1.0

Exact with the same commands as above, with one change: In the second line, use “stable main” instead of “unstable main”. This will switch to the newest stable release (whatever version it is at that moment).

Hi Chris,

as I don’t want to use a unstable version I played a little bit around with items and rules.
I also figured out a second bug:
When I restart openhab also the zwave binding is restarted. So far so good :wink:
I found out, that the “regular” update of the zwave device only takes place once. After the regular device update is once received by the zwave controller, it never receives a update again.
Maybe the binding crashes? The Problem is, that linked items (for example battery-level) aren’t updated anymore until you restart openhab2

Here’s what the eventlog says, after the update is received by the controller:
2017-02-05 10:22:04.668 [ThingUpdatedEvent ] - Thing ‘zwave:device:020e4758:node11’ has been updated.
2017-02-05 10:22:04.671 [hingStatusInfoChangedEvent] - ‘zwave:device:020e4758:node11’ changed from ONLINE: Node initialising: DYNAMIC_VALUES to ONLINE: Node initialising: DYNAMIC_END
2017-02-05 10:22:04.730 [hingStatusInfoChangedEvent] - ‘zwave:device:020e4758:node11’ changed from ONLINE: Node initialising: DYNAMIC_END to ONLINE: Node initialising: HEAL_START
2017-02-05 10:22:04.735 [hingStatusInfoChangedEvent] - ‘zwave:device:020e4758:node11’ changed from ONLINE: Node initialising: HEAL_START to ONLINE: Node initialising: DELETE_ROUTES
2017-02-05 10:22:04.923 [hingStatusInfoChangedEvent] - ‘zwave:device:020e4758:node11’ changed from ONLINE: Node initialising: DELETE_ROUTES to ONLINE: Node initialising: RETURN_ROUTES
2017-02-05 10:22:05.240 [hingStatusInfoChangedEvent] - ‘zwave:device:020e4758:node11’ changed from ONLINE: Node initialising: RETURN_ROUTES to ONLINE: Node initialising: NEIGHBORS
2017-02-05 10:22:05.267 [hingStatusInfoChangedEvent] - ‘zwave:device:020e4758:node11’ changed from ONLINE: Node initialising: NEIGHBORS to ONLINE

This message should (in my opinion) occur every time when the zwave smoke sensor wakes up and sends his regular update. But it only occurs once fo each device.

Maybe you should have also a look on this, when fixing the false alarm bug?

I don’t believe that the sensor sends anything when it wakes up so I don’t think this is true. Most sensors only send data when polled - or of course if there’s an actual alarm. During startup (DYNAMIC phase) the binding sends a poll so this is what causes the problem.

You know of course that the “stable” version is just the unstable version on a single date? I don’t really think that the “unstable” version is any less stable that the “stable” version… Unless you change to the new version (one changes are made) this won’t be fixed.

I looked at this issue yesterday and will probably merge the change to remove polling today.

Hi,

as the sensor is sleeping, how can it be polled?
And I think, that Battery-Level is only send when the sensor is waking up and sending the current status…
Otherwise the the battery would bei drained dramatically.
My Battery item isn’t updated since a day, also the device wakeup intervall is set to 4500 seconds…

Maybe than I also switch to unstable, after the issue is fixed. -> How do I get the information, that the issue is fixed?

All messages are queued in the binding until the device wakes up - this is normal. Once the device wakes up, messages are sent to the device.

For most devices, this is only sent when the binding polls the device. I know that some devices send this unsolicited, but most don’t in my experience - they need to be polled.

The device sleeps most of the time, so we queue the frames until it wakes - it doesn’t impact on battery.

OK, than I should give the snapshot a try :wink:
How do I get the information, that the issue has been fixed?

Monitor github -:

Or monitor the forum (ie here),

Hi,

I saw that https://github.com/openhab/org.openhab.binding.zwave/pull/346 is merged now, does this mean, that the error is fixed?
And I get the fix, if I’m switching to unstable release now?

Thanks a lot

Probably. But we have to see what happens with our sensors.

Not instantly. The package repositories (apt-get installations) only get updated from time to time (mostly during the night). As you are using this repositories, you have to wait at least until tomorrow to get the snapshot version where the fix is included.

ok, could you please reply here, when you have some results from testing?
Would be great!!!

And how can I figure out, if the fixed is included in the snapshot build?

Thanks a alot…

Hi, do you have any news, if the smoke sensors are working now?

You are kidding, right?

If you are SO impatient, go try it yourself.

I’m sorry. I didn’t want to rush you :wink:
But if you have some result it would be nice to get the information…

Thanks a lot in advance…

Hi again,

here’s my testing result.
I moved from snapshot to unstable version. That worked great according you description. Thanks a lot for that.
After being online again i figured out, the false alarms doesn’t occur any longer. Unfourtnately the zwave binding has an other issue with the smoke sensors:
I waited until the “wake up intervals” of the sensors was over (currently set to 4500 seconds for testing porposals).
No false alarm occured, but also the current battery level wasn’t reported from the smoke sensor.

I think I’m running on zwave version of 05th february:
openhab> list -s | grep openhab
openhab> list -s | grep openhab
9 | Active | 80 | 1.8.3 | openHAB OpenWebIf Action
10 | Active | 80 | 1.9.0.201607291201 | openHAB Edimax Binding
168 | Active | 90 | 2.1.0.201702051222 | openHAB Core
169 | Active | 80 | 2.1.0.201702051222 | openHAB Karaf Integration
171 | Resolved | 80 | 2.1.0.201702051222 | openHAB Sound Support, Hosts: 113
172 | Active | 80 | 2.1.0.201702051222 | openHAB Dashboard UI
178 | Active | 80 | 2.1.0.201702051222 | openHAB 1.x Compatibility Layer
204 | Active | 80 | 1.10.0.201702070218 | openHAB Mail Action
205 | Active | 80 | 1.10.0.201702070218 | openHAB XBMC Action
206 | Active | 80 | 2.1.0.201702051222 | avmFritz Binding
207 | Active | 80 | 2.1.0.201702051222 | Exec Binding
208 | Active | 80 | 1.10.0.201702070218 | openHAB Fritzbox Binding
209 | Active | 80 | 1.10.0.201702070218 | openHAB FritzboxTr064 Binding
210 | Active | 80 | 1.10.0.201702070218 | openHAB HTTP Binding
211 | Active | 80 | 2.1.0.201702051222 | Kodi Binding
212 | Active | 80 | 2.1.0.201702051222 | Network Binding
213 | Active | 80 | 1.10.0.201702070218 | Model Model
214 | Active | 80 | 1.10.0.201702070218 | openHAB WoL Binding
215 | Active | 80 | 2.1.0.201702051222 | ZWave Binding
216 | Active | 80 | 2.1.0.201702051222 | openHAB Cloud Connector Bundle
217 | Active | 80 | 2.1.0.201702051222 | openHAB REST Documentation
218 | Active | 80 | 1.10.0.201702070218 | openHAB RRD4j Persistence Bundle
219 | Resolved | 80 | 2.1.0.201702051222 | openHAB Basic UI Fragment, Hosts: 201
220 | Active | 80 | 2.1.0.201702051222 | openHAB Classic UI Fragment
221 | Active | 80 | 2.1.0.201702051222 | HABmin User Interface
222 | Active | 80 | 2.1.0.201702051222 | HABPanel User Interface
223 | Resolved | 80 | 2.1.0.201702051222 | openHAB Paper UI Theme Fragment, Hosts: 203

MAybe the Battery Level issue is fixed with the version chris provided yesterday.
So my question is:
How do I get the fixed version?
Is it an apt-get update and apt-upgrade to get the fixed version once it’s available?
Or do i have to uninstall and install the zwave binding?

Thanks a lot for your patience.

Regards

Helmar

As the latest snapshot (=unstable version) is from February 5th, the recent change from Chris couldn’t be integrated. He merged his fix on February 6th.

apt-get update/upgrade always gets the latest repository version …you can see here when a new snapshot-release is build. So as long as there isn’t a version from late 6th February (or even later), the fix won’t be in the zwave binding.

So I don’t know why there isn’t an alarm anymore in your environment. Some user reported that the false alarm occurs with the second wakeup, not the first. Maybe it’s still to come… :wink:

And I don’t think that there is a new issue with the battery level. It may take some time (=maybe a couple of wakeups) until the sensor reports all values. You should be patient.

Therefore I won’t make any tests myself as there is nothing to test atm…

Hi,

here we go the 2nd wakeup brought me the error back :wink:
2017-02-07 16:28:01.636 [ItemStateChangedEvent ] - i_zwave_11_Batterie changed from 11 to 100
2017-02-07 16:47:44.344 [ItemStateChangedEvent ] - i_zwave_12_Rauchalarm changed from OFF to ON
2017-02-07 16:47:44.435 [ItemStateChangedEvent ] - i_zwave_12_GehaeuseAlarm changed from OFF to ON
2017-02-07 16:47:44.535 [ItemStateChangedEvent ] - i_zwave_12_HardwareFehler changed from OFF to ON
2017-02-07 16:47:44.622 [ItemStateChangedEvent ] - i_zwave_12_BatterieAlarm changed from OFF to ON
2017-02-07 16:47:44.660 [ItemStateChangedEvent ] - i_zwave_12_Hitzealarm changed from OFF to ON
2017-02-07 16:47:44.993 [ItemStateChangedEvent ] - i_zwave_12_Temperatur changed from 22.699999999999999289457264239899814128875732421875 to 22.6
2017-02-07 16:47:45.075 [ItemStateChangedEvent ] - i_zwave_12_Batterie changed from 12 to 100
(Battery level update is also there…)

So I’ll wait until the new version is provided.
Then I’ll update with apt-get update/upgrade.

I’ll give feedback if the issue is fixed.

Regards

Helmut

What battery level issue? I’m not aware of any problems with battery level :confused:.

Don’t worry Chris. There isn’t an issue with the battery level.

1 Like

Hi everybody!
I’ve update to version 2.1.0.201702101116 today.
Now it works!!!
No False Alarms occurs. and battery level is updated as expected.
@Chris and @jaydee73: Thanks for you patience and support!!!

1 Like