openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.9k stars 3.59k forks source link

[mqtt][homeassistant] Support for JSON schema for light #6733

Closed N1k145 closed 3 years ago

N1k145 commented 4 years ago

What I noticed is that the Homeassistant MQTT Binding only supports the default schema for all types. When you use ESPHome with an FastLED light binding then the json schema is used. (I just tested FastLED and not the other RGB Light options of ESPHome)

From my standpoint it would be the best way to include support for the json schema in the plugin, as it is defined here: https://www.home-assistant.io/integrations/light.mqtt/ I saw on the forum that it is possible to translate to json by building the string in line. But I’m generally not a fan of a solution like this.

My question now is, is an implementation in the plugin the right approach? And is it doable without too much effort.

What I don’t know, what else is necessary in a way that the normal Color Picker can be used. One problem I see is for example that the brightness is part of the json message. So, the JSON payload would have to be built from the values of multiple channels. Is this an approach which is legal in openhab? (Im quite new to the platform)

This is the error message how the MQTT payload looks in my case. 16:02:34.855 [WARN ] [hab.binding.mqtt.generic.ChannelState] - Command '{"state":"OFF","brightness":255,"color":{"r":255,"g":255,"b":255}}' not supported by type 'ColorValue': {"state":"OFF","brightness":255,"color":{"r":255,"g":255,"b":255}} is not a valid RGB syntax

jochen314 commented 4 years ago

There are still many features missing from the HA spec. (first is switch #6739) My plan is to review each component one by one. But lights will probably be last, as there are many open points. Like: we need to intercept the change of a value (brightness) and trigger different messages to the device first, depending on the configuration. Once that is done, the JSON schema is probably not too hard any more.....

davidgraeff commented 4 years ago

Actually it would be nice if people from the OH community could propagate our own solutions to firmwares like ESPEasy instead of referring to HomeAssistant and that we miss HomeAssistant features all the time ;)

N1k145 commented 4 years ago

@davidgraeff

Actually it would be nice if people from the OH community could propagate our own solutions to firmwares like ESPEasy

For that I’m currently no deep enough in the topic, but are there implementation of some kind of IP based discovery or messaging solution from OH? (Based on MQTT or not)

I come from FHEM in combination with IOBroker, where they had the approach to support most of the proprietary stuff of the vendors. I had the feeling that OpenHAB followed a similar approach but in a more modern way.

There are currently many self-made Home Control solutions on the market, all with a slightly different approach, and Home Assistant defined a MQTT standard how to design the messages. That’s something OH would have to do too to push their solution to the firmwares, for an MQTT based solution. Alternatively define another standard which is similarly easy to implement.

Because I see the problem there that the firmware developers don’t want to build some custom implementation for there device in an home control solution, rather implement some standard which is used across multiple solutions or focus on only one solution.

davidgraeff commented 4 years ago

For that I’m currently no deep enough in the topic, but are there implementation of some kind of IP based discovery or messaging solution from OH? (Based on MQTT)

Yes. Homie: https://homieiot.github.io

I'm very grateful that Jochen took some of his time to rework my initial prototype/proof of concept-like implementation of the HomeAssistant based MQTT autodiscovery. It's just a bit ironic that people start to demand 100% HomeAssistant compatibility here. OH is a competing solution and should actually be able to replace HA completely.

Because I see the problem there that the firmware developers don’t want to build some custom implementation for there device in an home control solution

Not true. We are in contact with all ESP based firmware developers to push Homie in.

N1k145 commented 4 years ago

Yes. Homie: https://homieiot.github.io

I was not aware that homie comes from OH, I saw it in OH but it sounded from the name like just another Home Control System, so I did not look into it.

It's just a bit ironic that people start to demand 100% HomeAssistant compatibility here. OH is a competing solution and should actually be able to replace HA completely.

I agree with you in this point, from what I have seen when looking for MQTT Compatibility often they directly support HA, probably because of the discovery mechanism, but Homie also has this feature.

Not true. We are in contact with all ESP based firmware developers to push Homie in.

That was a statement based on my experience, also based on the fact that I did not know that there is a competing standard by OH, which is also supported in other Home Control systems. I will look forward to seeing if there comes an implementation. I maybe will have a look into it myself, as soon as I have the time.

hmerk commented 3 years ago

closed due to inactivity

pergolafabio commented 2 years ago

Guys, i'm new to OpenHab, using the Home Assistant mqtt binding, all switches are discovered, and i can add them as things from inbox However for the lighs, the channels gets corrupted, when i want to add points for adding to model, i always see errors like below, what can i do about it?

2022-07-26 17:44:47.491 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '{"state": "OFF"}' from channel 'mqtt:homeassistant_mqtt_5Flight_2Ewasplaats:e94f1500bd:mqtt_5Flight_2Ewasplaats:mqtt_5Flight_2Ewasplaats#light' not supported by type 'ColorValue': {"state": "OFF"} is not a valid string syntax 2022-07-26 17:47:02.634 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '{"state": "OFF"}' from channel 'mqtt:homeassistant_mqtt_5Flight_2Ewasplaats:e94f1500bd:mqtt_5Flight_2Ewasplaats:mqtt_5Flight_2Ewasplaats#light' not supported by type 'ColorValue': {"state": "OFF"} is not a valid string syntax 2022-07-26 17:50:24.625 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '{"state": "OFF"}' from channel 'mqtt:homeassistant_mqtt_5Flight_2Ewasplaats:e94f1500bd:mqtt_5Flight_2Ewasplaats:mqtt_5Flight_2Ewasplaats#light' not supported by type 'ColorValue': {"state": "OFF"} is not a valid string syntax

pergolafabio commented 2 years ago

using OH 3.3.0 btw, fresh install