Many thanks, this also solved it for me! I could meanwhile get all my rollershutters running again and also the thermostat is working properly. After a while, the door sensor joined in as well. I’m only still missing the smoke detectors and trying to wake them up manually didn’t yet lead to any success, so I hope to be seeing them soon.
What puzzles me a bit is that for one of my wall plug switches (an AEON Labs ZW075) is constantly writing this message package into the log:
2019-01-03 19:41:30.282 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 14 00 04 00 02 0E 32 02 21 74 00 00 00 00 00 00 00 00 00 00 86
2019-01-03 19:41:30.283 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 0E 32 02 21 74 00 00 00 00 00 00 00 00 00 00
2019-01-03 19:41:30.284 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 0E 32 02 21 74 00 00 00 00 00 00 00 00 00 00
2019-01-03 19:41:30.284 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-03 19:41:30.284 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Application Command Request (ALIVE:DONE)
2019-01-03 19:41:30.284 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: resetResendCount initComplete=true isDead=false
2019-01-03 19:41:30.285 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Incoming command class COMMAND_CLASS_METER, endpoint 0
2019-01-03 19:41:30.285 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: SECURITY NOT required on COMMAND_CLASS_METER
2019-01-03 19:41:30.285 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 2: Received COMMAND_CLASS_METER V3 METER_REPORT
2019-01-03 19:41:30.285 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 2: Meter: Type=Electric(1), Scale=W(2), Value=0E+1
2019-01-03 19:41:30.286 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveMeterValueEvent
2019-01-03 19:41:30.286 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_METER, value = 0E+1
2019-01-03 19:41:30.286 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Updating channel state zwave:device:30ef5acb:node2:meter_watts to 0 [DecimalType]
2019-01-03 19:41:30.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Commands processed 1.
2019-01-03 19:41:30.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@77ac7e0e.
2019-01-03 19:41:30.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-03 19:41:30.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-03 19:41:30.288 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-03 19:41:30.288 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
I have an equal one at another place as well that doesn’t flood so much into my logs. Both of them are switched on with a consumer being switched off, so I don’t quite understand why only this plug is constantly publishing 0 watts to the controller… Everything works fine in that regards though, it’s just the flooding of the logs (and maybe also the network itself, which makes me afraid of further issues coming up in the future). Maybe, someone has an idea of where to configure this? I’ve checked the properties in Paper UI, but they’re the same for both plugs.
Other than that, it turns out that the hexadecimal part of the identifier (e.g. zwave:device:a22ef60c:node7:sensor_door) has changed for all my devices somewhere on the way, so I’ll have to adjust my items accordingly.
Many many thanks once again, @chris for your splendid help on this one!