Fibaro smoke sensor (FGSD-002) / Not getting all values from the device

Maybe he wants to make sure it’s safe to come down the chimney next year ;).

This is something I need to look at further. The sensor uses the notification class and it is possible to poll notification states, but a device doesn’t need to respond to the poll.

No.

This is something I want to look at further when I get a chance. This command class is one that I want to look to convert to use a new codebase that is autogenerated directly from the Z-Wave documents but it’s a complex class (which is of course why I want to use the auto coded version - to make sure we have a compliant implementation)… It will take a little time probably but I’ll try and take a look over the next couple of weeks…

Ok, thanks. At least now I know that this is normal. Not that I think this is logical, but ok… :wink:

Also thanks for taking a look when time allows it.

Maybe - and I don’t necessarily disagree with you but many devices don’t respond to these polls.

When you think about it, it’s actually a little pointless - you don’t want to poll every 30 minutes to know your house is on fire - it’s the notifications you need. You just want to see the poll so you feel more comfortable that it’s working - that’s all (right? :wink: ).

You are right.

It’s just that I don’t like unfinished business. Like an undefined state. :slight_smile:

I agree - it doesn’t feel right and I’m sure we’ll sort out a solution to this in the near future…

I’ve not had a chance to test, but I’ve updated the binding tonight to improve polling of notifications to fix a problem with the Sensative Strip door sensor and I think it might also solve the problem with polling this as well…

Let me know if it works better with tomorrows binding - if it doesn’t I’ll take another look…

@chris, I suppose there is something going wrong again with this smoke sensors.

Yesterday I updated my snapshot release from #683 to 698. In #683 I had both sensors successfully integrated. Just out of curiosity I deleted the things and xml-files for both of my smoke sensors with the new build and re-added them.

They were discovered correctly as smoke sensor, but the initialization doesn’t seem to complete. About 18 hours later I still do not have new xml files. They woke up automatically and I also woke up one of them manually several times. And according to Habmin they are stuck at DYNAMIC VALUES:

According to the event log, I do get updates from the temperature channel. The other channels of course are quite non-operational as long as there isn’t some fire… :wink:

Could this be related to the recent changes of the polling mechanism?

If you need a debug log, I could create one while re-adding the device again. But as you also have this device, maybe it’s not necessary and you can verify this yourself?

If you can get a log it would be good as I’m away from home for 2 weeks. It could well be due to the polling change - I actually hoped that this change would have fixed the reading of the status as I think the new method should read event status as well.

Here is the log @chris. I deleted the thing (node 13) right before turning DEBUG on. Then I re-added it. I made a couple of manual wakeups (about 5 or 6) after that. Furthermore I changed the association group device status to “openhab controller”, since it was empty after re-adding. It went to “pending…” but even after the manual wakeups, it didn’t complete.

And furthermore, as already mentioned, no xml was created.

Thanks for having a look!

zwave.log.xml (411.5 KB)

Thanks - I’ve got an idea why this might be doing this. I changed the polling so that it should poll notification status’s as well now, but maybe during initialisation it’s not quite working…

I’ll see if I can come up with an update…

@jaydee73 I don’t suppose you have an XML for this device somewhere (I know it’s not creating one now, but maybe you have a backup you could post?)… (he says hopefully :wink: ).

Hmmm - or… can you email me the full logfile of the initialisation of the device? I want to take a look at what the device reports for supported alarms.

Somewhere in my backup I have. :wink:

node13.xml (17.6 KB)

If you need the log anyway, let me know. But I’m not sure what you mean by “full logfile of the initialisation”?! Isn’t this the log file that I posted above?

Thanks.

The log you posted looked quite short - it only had a few of the last messages, but thankfully the bit that was causing problems…

I’ll take a look at the XML first - hopefully it will answer my question.

I’ll shortly merge an update and kick off a build - I’d appreciate feedback… This only requests specific events in the NOTIFICATION class during initialisation which I think devices should respond to.

Any news on wether or not this helps (or makes things worse even)?

Since I am using the offline apt-get snapshot, I can only test your changes after a new build. I haven’t had yet the chance to do this today. I will try it this evening and come back with a report.

Ok - thanks.

Well, here is what I found out:

I upated through apt-get and had to switch the mechanism to the new repository at bintray first. Before I had:

195 | Active | 80 | 2.0.0.201701071314 | ZWave Binding

And after the update/upgrade:

195 | Active | 80 | 2.0.0.201701071702 | ZWave Binding

So only a slighty newer build. But gladly your changes were implemented in the newer build (at least I think so).

Initialisation went well and I also got the xml files soon afterwards. I got a wakeup timestamp in Habmin and no DYNAMIC VALUES message.

Nevertheless I got a minor issue: During the re-addition of one of the two sensors (node 8), I got the following log message:

2017-01-09 18:01:59.706 [ERROR] [curityCommandClassWithInitialization] - NODE 8: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2017-01-09 18:02:00.095 [ERROR] [curityCommandClassWithInitialization] - NODE 8: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2017-01-09 18:02:01.082 [ERROR] [curityCommandClassWithInitialization] - NODE 8: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting

This is somehow irritating, because I deactivated secure inclusion for the controller some weeks ago. And the messages didn’t appear for the other sensor (node 13). Does the sensor kind of remembers the initially inclusion method and maybe at that time secure inclusion was still active? Is this something to be concerned about?

So, is this already working for you? I’m going crazy with this, can’t get it to work. I can receive temperature data but no heat_alarm. I’m using OH2 2.1.0-1, with an item defined like this:

Switch alarma_temperatura_cocina "Alarma Temperatura Cocina [%s]" <siren> (sensor, temperatura, cocina, zwave, alarma) { channel="zwave:device:controller:node8:alarm_heat" }

I’ve tried everything I saw on the forums: Adding OH2 controller to association groups 2&4, adding the “respond_to_basic=true” (which seems not to be required anymore with OH2), etc. But even if the alarm is signalled visually (led blinks) I never get the notification on OH2.

Any clue of what might be wrong or anything else that can be tried?

many thanks in advance!!

PS: Configuration of the thing below.

56|690x397