Any idea what the problem (and hopefully) solution could be, @HarriedeGroot?
Haha, no problem. Not in a hurry and will be able to survive without.
Hope you saw a good movie/series… 
Version 3.3.2
- Color temperature fix
Wow, thx @HarriedeGroot!
Now I am able to change color temperature from within HA. The value in Homey gets updated accordingly (obviously). Great!
But the value set in Homey doesn’t get updated in Home Assistant.
And the setting ranges from 153-500. 1-100 would be more logical. Or perhaps 2200-4000 K.
Is that a MQTT Client problem and/or something that can be finetuned?
Thanks so far for the great help.
Bought you a few drinks on the newly opened terraces!
This was a quick fix.
The color handling actually needs a full rewrite…
The current implementation was mainly written for the connection with OpenHab, which is based on communication with RGB values. Hence the color topic. The hue, saturation and temperature topics should be made available themselves, to prevent some strange conversions and false assumptions.
I was looking at the chroma.js lib to do the heavy lifting.
Ok, thank you could arrange it so far then.
Something which could be on the to do list or is it simply too much work?
Nothing is ‘too much’ and everything is possible 
.
But rewriting the color handling needs some thinking and it is not a small change, possibly with breaking changes…
Hmmmm, I get it. 
Is that why commands from HA don’t get through to Homey too then?
That would be the biggest advantage, I suppose…
No, probably a wrong conversion from temperature to HSV and reverse. While this conversion isn’t necessary in the first place.
The current implementation detects if a device contains any color capabilities and translates them to HSV and/or RGB values and does the reversed calculations for incoming messages/data. This process can be skipped (partially) if the original capabilities (hue, saturation & temperature) are exposed themselves.
Hmmm, that is mostly too much programming language for me… Haha.
Well, would be great if it could be fixed, but of course I fully understand if that consumes too much time and effort…
I’m really thankful that you haven’t abandoned this app eventhough you’ve migrated away from Homey. I’m growing more and more reliant on the app each day it feels like. Right now I’m trying to migrate more stuff into MQTT to be platform agnostic kind of.
Anyway, I think it would be nice if you could add the optional “node_id” topic to the Home Assistant Discovery topic. Either to set it manually or leave it to “homey” or something.
Then if you make some own HA-discovery configs it’s easier to organize them in the MQTT tree structure.
Example:
homeassistant/sensor/homey/motion_sensor
I’ve been a long time user and the app has worked pretty flawlessly for a very long time since you helped me understand how MQTT worked.
Thanks for all your effort for this great app Harrie!
Last week I made the MQTT connection between my Homey and HA. Didn’t take a lot of time to get it running. 
This morning I noticed some Errors in my HA logbook:
2021-05-01 21:20:06 ERROR (MainThread) [homeassistant.util.logging] Exception in color_temp_received when handling msg on ‘homie/homey/light/lamp-tv-staand/color/v’: ‘50’
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/mqtt/debug_info.py”, line 32, in wrapper
msg_callback(msg)
File “/usr/src/homeassistant/homeassistant/components/mqtt/light/schema_basic.py”, line 354, in color_temp_received
self._color_temp = int(payload)
ValueError: invalid literal for int() with base 10: ‘326.5’
I didn’t notice these errors before, could this be related to the changes in the 3.3.2 version?
@Urban you’re correct. This error originates from the latest update. The light temperature value send from Homey to HA is invalid. Before this value wasn’t send at all and the latest update resolved the issue in the other direction (HA => Homey). The consequence: if the light temp is modified in Homey, the HA value isn’t updated accordingly.
By accident I also saw this error in my HA log this morning. Thanks for reporting.
@Camelen wouldn’t it be more logical to use the device name as node_id. So instead of …/homey/device-capability, it becomes …/device/capability.
Need to test if this also is the actual solution to the ‘naming’ issue.
Does HA use the optional node_id as a ‘device’ indicator and sub-topics will be the linked entities?
In doing a bit more investigation I guess you ARE using the optional node_id in the MQTT_hub already in the way you describe it in the post above right (as the device)?
And I also agree that it’s the logical way to do it. I was expecting the ability to use an extra topic.
And no HA does not seem to use the optional node_id for anything practical inside HA. Just as a help to structure the MQTT-tree better.
Edit:
Regarding the naming issue I can really see the problem. Since the sensor entities created needs to have the name with the capability included.
i.e. Table lights - Power
While the on/off capability shouldn’t have the capability in it’s name.
I’m not sure if that’s easily achievable or not and if there might be a problem with devices with two or more switches. But I guess they are considered different devices in Homey so I guess it should be fine if possible.
I expected HA to handle the naming correctly, since devices are first class members in HA nowadays. But that’s not the case…Both the device name and entity (=capability) name are provided. I once tried without the device name in the entity name, but that didn’t work as intended and the change was reversed. Don’t know if adding an alternative behavior for ‘onoff’ values is the way to go. Guess I’ll leave it as is for now … it’s easy to modify the names in HA afterwards anyway. You can even choose your own icon
1 Like
Yes indeed, I don’t see the name thing to be an issue really.
Version 3.3.3
- Color temperature fix: Homey => HA
Works like a charm, @HarriedeGroot!
Thanks, very much appreciated! 
To make it really neat, I have to find a way to change the min and max values in HA (now 153 and 500), but I suppose that has something to do with the calculations in HA.
Great work, thx!
