sorry , but its a good start… i’m indeed new to OpenHab
But:
Seems homeassistant.mqtt component is broken? i dont see reports of it anywhere?
I started a few weeks ago, i have an older DSM 6.x , so followed docs:
They point to this page for SPK release package
but release package is just missing, there are open issues on it on github, but its not updated , last update was from like october 2021 ?
as a new user, its not a good start 
In your first post you wrote that your are on OH 3…3.0.
That is a release that just recently was released.
Did you install Jinja- and JSON transformation ? They are listed as requirements for auto discovery for HA binding.
How to read this limitation:
The HomeAssistant Light Component only supports RGB color changes
I check later what release…
Yes json and Jinja installed , switch is working. , Light isn’t… I don’t have rgb or colorvalue on my matt lights, so no idea where it’s coming from
I’m indeed on 3.3.0, installed last month
'ColorValue': {"state": "OFF"} is not a valid string syntax
the code expects three elements ( split.length !=3 ):
extract from file openhab-addons/bundles/org.openhab.binding.mqtt.generic/src/main/java/org/openhab/binding/mqtt/generic/values/ColorValue.java
public void update(Command command) throws IllegalArgumentException {
HSBType oldvalue = (state == UnDefType.UNDEF) ? new HSBType() : (HSBType) state;
if (command instanceof HSBType) {
state = (HSBType) command;
} else if (command instanceof OnOffType) {
OnOffType boolValue = ((OnOffType) command);
PercentType minOn = new PercentType(Math.max(oldvalue.getBrightness().intValue(), onBrightness));
state = new HSBType(oldvalue.getHue(), oldvalue.getSaturation(),
boolValue == OnOffType.ON ? minOn : new PercentType(0));
} else if (command instanceof PercentType) {
state = new HSBType(oldvalue.getHue(), oldvalue.getSaturation(), (PercentType) command);
} else {
final String updatedValue = command.toString();
if (onValue.equals(updatedValue)) {
PercentType minOn = new PercentType(Math.max(oldvalue.getBrightness().intValue(), onBrightness));
state = new HSBType(oldvalue.getHue(), oldvalue.getSaturation(), minOn);
} else if (offValue.equals(updatedValue)) {
state = new HSBType(oldvalue.getHue(), oldvalue.getSaturation(), new PercentType(0));
} else {
String[] split = updatedValue.split(",");
if (split.length != 3) {
throw new IllegalArgumentException(updatedValue + " is not a valid string syntax");
}
switch (this.colorMode) {
case HSB:
state = new HSBType(updatedValue);
break;
case RGB:
state = HSBType.fromRGB(Integer.parseInt(split[0]), Integer.parseInt(split[1]),
Integer.parseInt(split[2]));
break;
case XYY:
HSBType tempState = HSBType.fromXY(Float.parseFloat(split[0]), Float.parseFloat(split[1]));
state = new HSBType(tempState.getHue(), tempState.getSaturation(), new PercentType(split[2]));
break;
default:
logger.warn("Non supported color mode");
}
}
}
}
I don’t use/own HA so I can’t do any experiments … I would assume that there must be a solution otherwise I would expect to see more of such reports here.
Is your bulb one that uses/supports different colors ?
If not does setting
"color_mode": true,
to
"color_mode": false,
at HA end helps ?
Could you use MQTT-explorer to capture the MQTT messages that are sent by HA ?
ah, thats interesting info indeed, my lights dont have color_mode anyway, i can just turn them on/off
Whit mqtt explorer i see indeed:
{
"uniq_id": "mqtt_light.wasplaats",
"name": "Wasplaats",
"stat_t": "homeassistant/light/wasplaats/state",
"avty_t": "homeassistant/light/wasplaats/availability",
"cmd_t": "homeassistant/light/wasplaats/set_light",
"schema": "json",
"color_mode": true,
"supported_color_modes": [
"onoff"
]
Now need to find a a way to set it to false, because i dont have defined that anywhere in HA
thnx for tip
ok, removed in mqtt everything about color, restarted Openhab, wasplaats was again discovered
{
"uniq_id": "mqtt_light.wasplaats",
"name": "Wasplaats",
"stat_t": "homeassistant/light/wasplaats/state",
"avty_t": "homeassistant/light/wasplaats/availability",
"cmd_t": "homeassistant/light/wasplaats/set_light",
"schema": "json"
}
2022-07-28 08:25:27.496 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'mqtt:homeassistant_mqtt_5Flight_2Ewasplaats:e94f1500bd:mqtt_5Flight_2Ewasplaats' to inbox.
2022-07-28 08:27:13.245 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '{"state": "ON"}' from channel 'mqtt:homeassistant_mqtt_5Flight_2Ewasplaats:e94f1500bd:mqtt_5Flight_2Ewasplaats:mqtt_5Flight_2Ewasplaats#light' not supported by type 'ColorValue': {"state": "ON"} is not a valid string syntax
But seems OpenHab is still expecting ColorValue , i dont understand why
Openhab is expecting 3 values here, but seems i only have 2
Below is being send by HA, but its not compatible with OpenHab, i need to make it compatible…
{"state": "ON", "color_mode": "onoff"}
any idea how the state should look like for OpenHab ?
EDIT: disregard that 3 , i also now tried adding an actual dimmer that has 3 values, bt still the same error:
2022-07-28 09:48:48.155 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '{"state": "ON", "brightness": 255, "color_mode": "brightness"}' from channel 'mqtt:homeassistant_mqtt_5Flight_2Edimmer1:e94f1500bd:mqtt_5Flight_2Edimmer1:mqtt_5Flight_2Edimmer1#light' not supported by type 'ColorValue': For input string: "{"state": "ON""
Not sure what Openhab is expecting in the lights domain
Don’t sell yourself short. A persons value on this form should be weighed by their ability to convey an idea or provide instruction on how to accoplish something. Your post starts out doing a good job of that.
Maybe you can be off some assistance as I am struggling with MQTT.
Working with a Kasa Smart Plug HS103
I have a THING. tplinksmarthome:hs103:xxxxxx
It has a CHANNEL Power switch (Switch) Device is operable when channel has state ON.
I created an ITEM called “MyPLUG”
It has tplinksmarthome:hs103:xxxxxx.switch within the its CHANNEL LINKS.
I created a Generic MQTT Thing and connected it to the MQTT Broker
Within the Generic MQTT Thing I created “MQTT MyPLUG Thing” with oh3/plug/mqtt_myplug/cmd and oh3/plug/mqtt_myplug/state. RETAIND and IS COMMAND
I added the MQTT MyPLUG Thing to the ITEM called “MyPLUG”
When I use the openHAB UI to turn the plug ON or OFF the plug works accordingly and ON or OFF is written to oh3/plug/mqtt_myplug/cmd
However oh3/plug/mqtt_myplug/state NEVER changes.
Shouldn’t the STATE change to the state of the physical device?
It is the device’s job to publish a message to its state topic when it changes state for any reason. So first verify that. If that’s not happening you’ve found your problem. Maybe the device is misconfigured. Maybe the device is reporting to a different topic. Maybe the device doesn’t report it’s state at all.
If you’ve confirmed that the message is being published by the device to this topic that OH subscribes to, than you’ve something wrong with your Channel config.
As I said on another thread, you have to understand your data flows. What messages are published to what topics under what circumstances.
This is what I am trying to understand.
How do I figure out what topic, if any, the Insteon Dimmer is reporting to? I am guessing the Insteon binding plays a big role in this.
Do I use the Insteon Binding Channel Names? How would that be formatted for MQTT?
When I create a Generic MQTT Thing do I create one ( 1 ) for each device and then add a channel for each topic? Or do I create a single Generic MQTT Thing and add a channel for each device and then link that device?
I have eliminated HA from the equation for now until I can get this issue resolved.
EDIT: …the same thing goes for the Kasa plug.
Nope. Not at all.
Again, I’m pleading, forget about OH’s config.
Get a piece of paper. Chart out the data flow that you require. For example:
Switch manually turned on
Person flips switch -> Insteon reports new ON state -> MQTT publishes ON to /blah/blah/state
Switch manually triggered from MainUI Widget
Person taps toggle -> OH sends command to Insteon Switch to turn it ON -> Insteon reports new state -> MQTT publishes ON to /blah/blah/state
MQTT command to turn on the switch
ON received on /blah/blah/cmd -> MQTT binding receives the command -> Insteon commanded to new ON state -> Insteon reports new ON state -> MQTT publishes ON to /blah/blah/state
And so on (there is probably another dozen or so data flows). Notice though how it always ends with “Insteon reports ->. MQTT publishes”. That’s two separate steps. You have to make that happen, either through a Rule or a Profile. OH doesn’t do that automatically.
Then start configuring OH to handle these data flows. There is more than one possible approach. The best depends on the collection of data flows.
And I’ve said this before, but OH operates on Items. Items are abstracted from the technologies they are attached to. The names of the topics in MQTT have nothing to do with Insteon. That needs to be driven by what ever is consuming the MQTT messages OH sends and receives.
I’ve said this before. The great power of OH is that it abstracts the technologies. The Insteon Things get linked to Items. MQTT gets linked to Items. Once you have Items, a Switch is a Switch. It doesn’t matter.
Insteon does not know and does not care anything about MQTT and vice versa.
This should be answered in the concepts section of the OH docs. Ultimately what you should take from this is that it doesn’t matter. Typically one Thing will represent one physical device but ultimately it doesn’t matter. What matters to OH are the Items.