My node 2 and 3 has like a vendor code in front (SW-ZCS-1 and AN157) but node 6 doesn’t.
I also found a typo in node 2, where Pdgin instead of Plug-in (like in Node6).
Yes, it does. In the case of the BeNext devices, the vendor code, as best as I can find in any of their documentation was plugindimmer. If you know where to find ‘proper’ codes, I’d prefer to change it, but I was unable to find any.
I think this must have been fixed already as it looks correct in the database. If you want to fix it in your system, you need to update the thing configuration.
Here’s maybe a basic question. But:- since yesterday, I have “lost” a couple of nodes. I think it happened when I run around the house adding a “new batch”. The one that I’m concentrating on now is node 24, a Fibaro Wall socket.
If I look in the log it says it is not initialized e.g.:
09:41:44.007 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Polling...
09:41:44.007 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Polling deferred until initialisation complete
And when I push the button on the unit;
10:44:54.272 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 18 03 25 03 FF 30
10:44:54.273 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
10:44:54.273 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 18 03 25 03 FF 30
10:44:54.273 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 18 03 25 03 FF 30
10:44:54.273 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 03 25 03 FF
10:44:54.273 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message.
10:44:54.982 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 18 06 31 05 04 22 00 29 D2
10:44:54.982 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
10:44:54.983 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 04 00 18 06 31 05 04 22 00 29 D2
10:44:54.983 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0C 00 04 00 18 06 31 05 04 22 00 29 D2
10:44:54.983 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 06 31 05 04 22 00 29
10:44:54.983 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message.
There’s nothing else in the log, that relates to node 24.
I have at least two other nodes with similar behavior, where at least two of them used to work fine.
Restarting oh does not make any difference, and I update binding once a day. Openhab is about one or two days old by now.
This looks fine - it’s sending you and alarm and it looks like it’s updated the channel? Is that not correct?
No - sorry, I’ve not had a chance to look at this. I’ll take a look over the next few days.
Ummm - yes there is. I can see a message from Node 24, and a statement that it’s being ignored because the device isn’t yet initialised??
You don’t say what this node is, but it looks like it’s not completed initialisation. It therefore needs to be woken up. Maybe the wakeup class isn’t configured, in which case it will need to be manually woken up.
ok one question ahead:
bhuism above posted his log: he gets an update for: Incoming command class SENSOR_BINARY
I do get an update on the same sensor and motion: Incoming command class ALARM
also both parameters (binary, alarm) do not get an update either on basicui nor within habmin (ever):
Is this for exactly the same device? Maybe there’s a setting to change the command class being used (often there is) or maybe they have different firmware and the manufacturer has changed the way it works. Either way, the binding can’t change this - it needs to deal with whatever the device sends…
Maybe there’s a bug in the converter - I’ll take a look. From the log you posted above it looks like it should say ON…
?? There’s nothing else in the log except the part that I just presented.
You don’t say what this node is, but it looks like it’s not completed initialisation. It therefore needs to be woken up. Maybe the wakeup class isn’t configured, in which case it will need to be manually woken up.
I thought I wrote it, but more explicitly it is a FGWPE/F-101.
Apart from pressing the button, I have now also tried to unplug it. This gives similar messages;
11:23:11.840 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 18 06 31 05 04 22 00 00 FB 11:23:11.841 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0 11:23:11.841 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 04 00 18 06 31 05 04 22 00 00 FB 11:23:11.841 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0C 00 04 00 18 06 31 05 04 22 00 00 FB 11:23:11.841 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 06 31 05 04 22 00 00 11:23:11.841 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message. 11:23:12.871 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 18 0A 32 02 21 44 00 00 10 DC 00 00 60 11:23:12.871 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0 11:23:12.872 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 18 0A 32 02 21 44 00 00 10 DC 00 00 60 11:23:12.872 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 18 0A 32 02 21 44 00 00 10 DC 00 00 60 11:23:12.872 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 0A 32 02 21 44 00 00 10 DC 00 00 11:23:12.872 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message. 11:23:14.343 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 18 03 25 03 FF 30 11:23:14.343 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0 11:23:14.343 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 18 03 25 03 FF 30 11:23:14.343 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 18 03 25 03 FF 30 11:23:14.343 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 03 25 03 FF 11:23:14.344 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message. 11:23:15.052 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 18 06 31 05 04 22 00 25 DE 11:23:15.053 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0 11:23:15.053 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 04 00 18 06 31 05 04 22 00 25 DE 11:23:15.053 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0C 00 04 00 18 06 31 05 04 22 00 25 DE 11:23:15.053 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 06 31 05 04 22 00 25 11:23:15.053 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message. 11:23:16.155 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0E 00 04 00 24 08 32 02 21 12 00 07 00 00 DD 11:23:16.155 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0 11:23:16.155 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0E 00 04 00 24 08 32 02 21 12 00 07 00 00 DD 11:23:16.155 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0E 00 04 00 24 08 32 02 21 12 00 07 00 00 DD
I guess maybe you are suggesting to simply reset the nodes that where caught in this limbo?
Sorry - I misread your message, you’re right…[quote=“vespaman, post:471, topic:7522”]
I guess maybe you are suggesting to simply reset the nodes that where caught in this limbo?
[/quote]
No - I’m just stating that it hasn’t finished initialisation and that’s why it’s not working. It should finish initialisation quite quickly if it’s a mains powered device, although I have seen here some devices sit in the WAIT state for a long time and I’ve not looked at this yet (maybe I should 
). It’s hard to say what’s happening with the device without seeing a longer log during the initialisation phase, but it might be the same issue.
Resetting the node is unlikely to help…
Hi again,
Now the meter is found correctly, but i only see channel for 2 phases. My meter has 3 clamps, can i add 1 to configuration, or does it need to be added in the template?
/Henrik
Just to confirm, this is for the DSB28 - correct?
You need to add it to the database so that the channels get updated correctly in the binding. Currently there are 3 endpoints in the database - the root, and 2 others. Do you know if the root (ie endpoint 0) is like a ‘total’ of the other 2? If so, then the route forward is to add another endpoint (3), and copy exactly the same as endpoint 1 and 2. The other thing we should do is to change the names. If we know that endpoint 0 is a ‘whole house’ or ‘total’, then we should make the names ‘Whole House Electric meter (watts)’, and for endpoint 1, ‘Clamp 1 Electric meter (watts)’ sort of thing. The names in there at the moment are auto generated from reading the XML…
If the above is correct, can you make the database update?
at the karaf shell prompt, type > items
You can get to the shell by running: runtime/karaf/bin/client
This is awesome! Any chance to make it different colors - impossible to see for a color blind… 
And also, for the unidirectional route, is it possible to make it an arrow to show which way? 
Currently the colours represent the state of the node (online/offline) and the border colour is grey if the node isn’t listening (normally associated with battery devices). I’m open to using different colours, or maybe having a single ‘colour blind’ option to use different colours…
Arrows should be possible when I get a chance…
Newly found unknonwn:
Everspring ST812 Flood Detector
xml: https://drive.google.com/open?id=0B1-V_L_iOMcSaFRJZUE0aENXOVE
This is already in the database. If it’s not showing up, then can you email me a log file during the initialisation sequence - when this device is discovered. A few people have reported devices not being detected properly, but I’ve not managed to trace this…
Chris,
What are the prerequisites for getting this nice feature to work? I only get a blank page. I’m guessing I’m missing some set-up somewhere!?
Only that you need to be running a recent version of both HABmin, and the Z-Wave binding. Ideally, it should be from today.