Open zolakk opened 1 year ago
What device is sending this state? It is a bit unusuall. Don;t think adding a trim function to the state would be a good idea. You could also use a transform file ?
It's the ring-mqtt project, using the Home Assistant mqtt but I can easily see other similar projects doing the same on accident. I patched it sending the spaces on my local instance to fix the issue but I figured I would open a bug here since it didn't seem like a valid case for trying to send ' ON ' or ' OFF ' for switch channels and it doesn't seem to bother Home Assistant at all, presumably they trim their switch inputs to avoid errors. I agree that maybe adding a blanket trim would not be a good idea since there's cases for things like string channels for example where you might legitimately want that data. A better suggestion would be to apply a trim in the switch or dimmer auto generated channel types with the HA MQTT topics and not for any other type or something like that since there's no case where you would want to send an invalid state to a switch that I can see. Perhaps that's more of an issue that should be raised in core and not here since that would fix invalid switch inputs from spaces in any instance?
I also didn't think about a transform file since it seems more of a workaround than a real fix, but this inline JS transform seems to work as a backup. I'll just have to remember to add it anywhere where these channels are used so thanks for the suggestion on that.
|(function(i) { return (i.trim()); })(input)
Are you sure Home Assistant strips spaces? I can't find anywhere that it does so. https://github.com/home-assistant/core/blob/dev/homeassistant/components/mqtt/mixins.py#L511 is where it handles incoming availability messages. It's doing a straight comparison to available/not available values, and I don't see any strip
calls there or in the template processor: https://github.com/home-assistant/core/blob/dev/homeassistant/components/mqtt/models.py#L173.
I don't know if or how it strips them exactly but it certainly doesn't seem to care somehow. I run Home Assistant in parallel to OpenHAB and Home Assistant doesn't seem to care one bit about the incoming message of " ON " or " OFF " while OpenHAB throws an error.
Looks like with 4.0 M3 the trim incoming transformation workaround is not working anymore, I think because the issue is happening before it gets to the channel to item level so those items never get updated.
Looks like with 4.0 M3 the trim incoming transformation workaround is not working anymore, I think because the issue is happening before it gets to the channel to item level so those items never get updated.
Could you use 4.3.0 snapshot and show your item configuration? You should be able to transform or use a map.
Expected Behavior
State update should update correctly
Current Behavior
I get the following in my logs because the sender appears to put spaces around the state (e.g. ' OFF ' instead of 'OFF'):
2022-12-07 10:29:24.906 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command ' OFF ' from channel 'mqtt:homeassistant_a1d2b322_2Dfa3d_2D4575_2D9bfd_2Dc4f46f7520fa:mqttBroker:a1d2b322_2Dfa3d_2D4575_2D9bfd_2Dc4f46f7520fa:a1d2b322_2Dfa3d_2D4575_2D9bfd_2Dc4f46f7520fa_5Ftamper#sensor' not supported by type 'OnOffValue': No enum constant org.openhab.core.library.types.OnOffType. OFF
Possible Solution
Trim the incoming messages
Steps to Reproduce (for Bugs)
Context
Can't use those channels since they won't update properly
Your Environment