I have several Fibaro Motion Sensors (FGMS-001), some of them are firmware 2.7 and some are 3.2.
One of the 2.7 ones seems to have channels for 3.2, this results in the alarm_tamper channel getting triggered when motion is sensed (and when tamper is sensed), and the alarm_motion channel never being triggered.
TAMPER:
2017-09-22 13:09:54.309 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 62: Application Command Request (ALIVE:WAIT)
2017-09-22 13:09:54.310 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 62: Incoming command class SENSOR_ALARM
2017-09-22 13:09:54.312 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 62: Received SENSOR_ALARM command V1
2017-09-22 13:09:54.313 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 62: Alarm Report: Source=62, Type=General(0), Value=255
2017-09-22 13:09:54.315 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Got an event from Z-Wave network: ZWaveAlarmSensorValueEvent
2017-09-22 13:09:54.316 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_ALARM, value = 255
2017-09-22 13:09:56.392 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 62: Application Command Request (ALIVE:WAIT)
2017-09-22 13:09:56.392 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 62: Incoming command class SENSOR_BINARY
2017-09-22 13:09:56.393 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 62: Received SENSOR_BINARY command V1
2017-09-22 13:09:56.394 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 62: Sensor Binary report, type=Unknown, value=255
2017-09-22 13:09:56.395 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2017-09-22 13:09:56.396 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 255
2017-09-22 13:09:56.397 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Updating channel state zwave:device:abc5a77a:node62:alarm_tamper to ON [OnOffType]
2017-09-22 13:10:26.901 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 62: Application Command Request (ALIVE:WAIT)
2017-09-22 13:10:26.903 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 62: Incoming command class SENSOR_BINARY
2017-09-22 13:10:26.904 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 62: Received SENSOR_BINARY command V1
2017-09-22 13:10:26.905 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 62: Sensor Binary report, type=Unknown, value=0
2017-09-22 13:10:26.907 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2017-09-22 13:10:26.908 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 0
2017-09-22 13:10:26.910 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Updating channel state zwave:device:abc5a77a:node62:alarm_tamper to OFF [OnOffType]
MOTION:
2017-09-22 13:10:49.012 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 62: Application Command Request (ALIVE:WAIT)
2017-09-22 13:10:49.013 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 62: Incoming command class SENSOR_BINARY
2017-09-22 13:10:49.013 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 62: Received SENSOR_BINARY command V1
2017-09-22 13:10:49.013 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 62: Sensor Binary report, type=Unknown, value=255
2017-09-22 13:10:49.014 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2017-09-22 13:10:49.015 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 255
2017-09-22 13:10:49.015 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Updating channel state zwave:device:abc5a77a:node62:alarm_tamper to ON [OnOffType]
2017-09-22 13:11:19.755 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 62: Application Command Request (ALIVE:WAIT)
2017-09-22 13:11:19.756 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 62: Incoming command class SENSOR_BINARY
2017-09-22 13:11:19.757 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 62: Received SENSOR_BINARY command V1
2017-09-22 13:11:19.758 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 62: Sensor Binary report, type=Unknown, value=0
2017-09-22 13:11:19.759 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2017-09-22 13:11:19.759 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 0
2017-09-22 13:11:19.760 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 62: Updating channel state zwave:device:abc5a77a:node62:alarm_tamper to OFF [OnOffType]
Hmm. Yes, FGMS motion messages should be of alarm_motion type, but they’re of “Unknown” type and trigger your alarm_tamper channel.
Have you tried to reinitialize the device in habmin ? Check node.xml after that for alarm_motion class.
There’s also device parameters #24 and #26 to control tamper, try experimenting. You might have set #24 to report using proprietary classes.
Hmmm - I think you’re mixing things up here. alarm_motion is a channel type - the Unknown you see in the log is not related to this - it’s part of the protocol - not OH. I think this is probably correct, but without seeing the received data from the debug log I can’t be sure - if that can be provided, it would be useful.
You’re of course right, I was temporarily inclined to believe it should actually send an ALARM message instead of SENSOR_BINARY.
But that’s nonsense, looking into my own logs, I see it’s (still) supposed to be sensor binary messages. Mine have type=Unknown, too. However, they are properly mapped to the alarm_motion channel (the one I looked up has a 2.6 firmware).
So @Dan_Bellandi, please provide more info. How recent is your OH version, have you tried the snapshot version ?
And send a log to show raw message contents, too. Preferrably use @chris’ log viewer to decode it yourself.
@mstormi When you say reinitialize the device in habmin what do you mean? Exclude and the include it with the controller?
The node.xml files do not seem to have any ALARM_MOTION, they have SENSOR_ALARM and SENSOR_BINARY. How/where is the mapping of command classes to channels defined?
I have three sensors with 2.7 firmware (Type/ID 0800:2001) that work properly and have these channels:
sensor_binary – motion triggers this
sensor_temperature
sensor_luminance
battery-level
alarm_general
I have one sensor with 3.2 firmware (Type/ID 0801:2001) that works properly and has these channels:
sensor_binary
sensor_temperature
sensor_seismicintensity
sensor_luminance
alarm_motion – motion triggers this
alarm_tamper
battery-level
alarm_general
The “confused” sensor with 2.7 firmware (Type/ID: 0800:2001) has channels similar to the 3.2 one but not all of them:
alarm_tamper – motion (and tamper) triggers this
sensor_temperature
sensor_luminance
battery-level
alarm_motion – untriggered
@chris My earlier log was grep’d for node 62, here’s a snippet from a motion event with the raw data:
I can’t see any obvious mechanism for this. I would suggest to try deleting the thing and add it back again so that it re-reads the definition. If this doesn’t work I’ll have another think about it and maybe add some more debug.
No, mark the thing in habmin and select the tools button in the upper right corner, then select extended and re-initialize (as my habmin isn’t set to English, the exact naming may be different).
If that doesn’t work (at times you need to try multiple times), you might want to copy a proper xml file to the “confused” sensor’s (and change the nodeID in there to match).
Eventually delete the thing and re-discover the device.
That’s inside the binding … but since you’re using an up-to-date version, that should be working fine.
I don’t think there’s anything wrong with the XML. Of course, feel free to try this, but given the message is being processed ok, I don’t think it will help.
I certainly would not suggest to copy XMLs from some other source - iXML files are not meant to be “user servicable” - they are there to save binding data… If the XML file does have an error (unlikely), then copying the file from another source to try and fix it can at best be a temporary solution and it will at some point revert, so it’s best to try and find the problem.
But if identical XML input from two sensors (w/ the same firmware) was mapped to different channels (by the same binding/database version), there should not be any difference in output. But it is, so the XMLs must be different, no ? @Dan_Bellandi, could you post them ?
The xml is not used to map command classes to channels - it has no link at all to channels. The xml only stores data that the binding downloads from the device - its only at the protocol layer - not the thing layer.
Maybe you are getting confused with the other xml that comes from the database that does have this link? However that xml is not something that you can easily see, and you can’t edit it (well, not easily).
Once a thing has been created, the link from classes to channels is stored in the Jain database - this is why I suggested to delete the thing - this will clear out this link.
I’m getting more and more confused … well, I was referring to the XML file that the binding is writing out after a device is initialized, to get stored in /var/lib/… . If there were two identical devices on the ‘input’ side of the system and one single common binding-database-whatever processing sequence produces two different outputs (in terms of the channels that messages get mapped to), then there must have been a difference on the input side, which are the XMLs in my example. A difference that should not have been there as the devices are said to be identical … or am I missing something here ? Hence my conclusion that one of them is bad and thus the proposal to re-initialize the ‘confused’ device (and to delete/rediscover the thing, too) to re-create a proper, hopefully identical XML file.
EDIT: ok, now as AFAIK the thing got created on discovery only, it could have been the case that the XML was bad at that point in time but that is has been corrected since, but that’s not reflected in jsondb yet, so in that case it should be sufficient to delete/re-create the thing.
I understand the XML is directly coming from the device. By ‘bad’ I mean syntactically correct but contents-wise ‘bad’ or ‘incomplete’, i.e. it does not properly reflect all the device capabilities because <whatever> went wrong during its initialization.
I strongly suggest not to worry about the XML that the binding writes. This only saves information that comes DIRECTLY from the device itself. It has no link to the channels.
It’s clear from the log provided above that the processing is being processed correctly at this level - ie it’s being processed by the command correct class.
Channel information is stored in a completely different place. Channels are not processed at all in the command class classes - there is a clear separation in the binding between these layers.
I hope that helps (sorry if it’s still confusing).
So I removed and re-added it to the controller and now motion is reported on the proper channel. Still with a different channel name than other 2.7 sensors though, oddly.
However, I’m thinking that this appears to just be a faulty device, as now I’m noticing that that it only detects motion within about 2 feet. So based on that, I wouldn’t be surprised if there’s something else wrong with the device itself regarding the channel irregularities.
We’re talking about different things now, I’m not talking about the mapping (not any more).
Try taking my simple (an outsider’s, of course) abstract point of view on what’s happening:
There’s a single, common algorithm (syntax processing and mapping in binding, database etc.) applied to two input sets of data (the data coming from 2 devices of identical firmware) that result in two differing sets of output data (the channels that are used in the end). Conclusion: the input data sets must have been different.
Which is because either the devices are not truely identical (and send different XML data right away), or because something went wrong on their way into the XML file (incomplete initialization, data is from yet another device to respond to have the same nodeID, whatever, just guessing …). That’s why I wanted Dan to show the XML files…
And since the thing contents in jsondb is sort of a ‘(cache) storage of earlier computation run outputs’ (see EDIT section of my previous post), I agreed with your proposal to delete the thing (‘clean the cache’).
Anyway, just seeing that Dan just answered while I was writing, so I suggest we stop further discussion.
.
… well, I was referring to the XML file that the binding is writing out after a device is initialized, to get stored in