mySensors OpenHAB is returning 0 to the request from a node

I have an RGB light configured with mySensor.
Changing the value of the light works great without any problems.
However when the light restarts etc. and needs to get its last value back from OpenHAB via request it only receives 0.

Here is the LOG output

09:57:44.460 [DEBUG] [ors.internal.gateway.MySensorsGateway] - Node 50 found in gateway
09:57:44.460 [DEBUG] [ors.internal.gateway.MySensorsGateway] - Child 0 found in node 50
09:57:44.461 [DEBUG] [ors.internal.gateway.MySensorsGateway] - Request received!
09:57:44.462 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;6142905 TSF:MSG:READ,50-50-0,s=1,c=2,t=40,pt=0,l=0,sg=0:
09:57:44.462 [DEBUG] [orsAbstractConnection$MySensorsWriter] - Sending to MySensors: 50;0;1;0;40;0
09:57:44.462 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 50;1;2;0;40;

OpenHAB does react on the request but only sends a 0. When I look at the status of the Child 0 Items via

smarthome:status LEDBettAllColor

I get


So the RGB values are stored in this Item.

Additionaly here are the item and thing file:


Color LEDBettAllColor "LEDStrip Bett All Color" (Eltern, MySensors, gLEDBettElternColor) { channel="mysensors:rgbLight:gateway:thLEDBettAllColor:rgb" }


rgbLight thLEDBettAllColor "LED Bett All Color" [ nodeId=50, childId=0, requestAck=true ]

ok strange.
When I put a color picker into the habpanel I see that the color is displayed correctly but the request from the node gets 0.
However as soon as I click the color on the habpanel and click accept again so no change in color just accept the current one and I reboot the node so it does call the request once more, it gets the right color from openHAB.

I had to restart OpenHAB a few days ago and I didn’t change the color since then. The mysql persistence did restore the correct color for the color picker from the datebase but somehow did not further hand the data over to the MySensor binding…

might this be a bug?

It doesn’t work quite like that. The “restore” restores the state of your Item, which of course will then get displayed on the picker.

What happens here is that a command is sent from UI to your Item.
In the normal course of events, commands (not states) are what get sent to devices. All good here.

I will make a guess here - when something asks mySensors binding “what was the most recent thing I was supposed to do”, the answer is the last command. Item state is irrelevant.

After an openHAB or binding restart, the “last command” is null.

so therefore it looks like a bug since when an RGB device like a light etc. asks for it last supposed state or color or whatever it should return the last stored value etc. from the DB or state and not the last command executed or known especially when this is NULL

I don’t know what the “rules” of mySensors are, as to what should happen.
What should happen when the user does not restore Items, so that there is no state to offer? Or at first use, or with a new device?
openHAB bindings do not not normally interrogate Items about their states, they act on commands.

I don’t know if this is what is actually happening - it’s a guess. You could help by looking closely to see if the idea is consistent with your experience.

You can file a github request, whether you call it a bug or an enhancement request.

Perhaps there are alternative solutions - bring out a devices “help me” request to a separate channel, so that the user chooses how to respond.

There are openHAB based workarounds, such as sending a command regardless of device availability when an Item is restored.