Hi guy’s. I’m totally new with this MQTT, but studied hard this weekend and managed to create a nice and working node-red MQTT dashboard. But I’m facing a problem with the lights. I want to control my mi-lights, but I’m only able to control the on/off, brightness and mode… I can’t figure out what I need for “topic” to control the color.
I’m not sure what you exactly want, or how can I can generate such a “expanded topic”? I did watch the incoming messages and made a debug dump when I changed the color. These messages are the last lines from my previous post (under “When I watch the debug, and I change the lights hue, I see:”).
If you need more, can you please elaborate how I generate this info?
This script searches for the light and changes the hue:
(Example topic string: “homey/lights/light-name/set 360”)
let devices = await Homey.devices.getDevices();
function CleanName(NameToChange) { //Removes spaces, - and _
var NewName=NameToChange
return NewName.replace(/_/g, '').replace(/\s+/g, '').replace(/-/g, '').toLowerCase();
}
var topic=args[0]; //retrieve argument
var LightName=CleanName(topic.split("/")[2]); //distilling light name
var HueValue=parseInt(topic.split("set ")[1])/360; //converting 360 degree string to 0-1 float
_.forEach(devices, device => { //search trough devices for light name
if (CleanName(device.name)==LightName) {
device.setCapabilityValue('light_hue', HueValue); // set the hue;
}
});
Ah, that’s a nice piece of software. If I change the color of a light, it changes the hsv and h parameter, and directly after that the rgb,r,g,b parameters… but these values always stay 255.
Can you tell me (based on this screenshot) what topic I need to use to change the hue of the light?
I expected: homie/homey-topic/lampen-bureau/color/h/set: 100
but that does not seem to work.
Found something intersting when I press broadcast button inside the MQTT hub…
There is a topic (homeassistant/light/lampen-bureau) showing up containing:
These lines are interesting:
“hs_command_topic”:“homie/homey-topic/lampen-bureau/color/set”
“hs_value_template”:"{{ value_json.h }},{{ value_json.s }}"
But I don’t understand how “{{ value_json.h }},{{ value_json.s }}” should be formatted.
There is no /set command available for the H value. Normally in homie the only topic that can be /set is the parent topic in your case color.
So you will have to control the Hue by setting it within that topic
color = H,S,V looks like the format
That topic is the one that contains a topic/value/type description of each of the devices exposed to Home Assistant - it sends the information to HA for HA Discovery to work it’s magic and create devices in the UI. Aside from containing the type, state and command topics it can also contain transforms for the values e.g. mapping HA’s 0-255 brightness to HE’s 0-100.
I think this is extracting the h and s values from a json payload to be placed back as integers into the color topic. I’m assuming therefore that HomeAssistant is supplying color change values in json format. Alternatively it may be assembling a json payload from color integers to present to HomeAssistant.
From memory I seem to remember that either HA or HE only provides the two values h and s in one message and v is contained in another message and hence the h,s,v value has to be reassembled to be complete.
For you with your NodeRED implementation the transforms and the HA Discovery messages are not relevant (although you could discover devices in NR is you wanted from the homeassistant topic)
Re RGB - I suspect the bulb has to be in that $format for those values to be used - and then hsv wouldn’t work . Again separate R G or B would only be settable via the color/set topic but it would be an r,g,b value
I don’t think so, but you can use the MQTT Client to send MQTT messages from a flow. If you trigger these flows on zone change, you can sent whatever MQTT message you want.
Sure, I have implemented it in that way already as a workaround… But by my opinion it would be more consistent if the message comes from MQTT Hub (that covers all Homey events and stats). if the zone is the official object of ‘Homey world’ and Homey generates by itself ‘zone events’ that are catchable in flow…
I try to use MQTT Hub to create a daschboard
Config:
Openhab on Synology DS214 play Without docker
MQTT client, HUB, Brocker installed on Homey
When I setup OpenHab on , Brocker and homie device can be online
So I can link devices and control its
BUT, if I disconnect brocker or if I restart Homey or after couples of hours, MQTT homie device appears as uninitialised, and the only way to make it reliable again is to remove MQTT Device on open hab and ceate it again with the same setting.
I really don’t understand what happen
Is someone already meet this issu ?
Thank you for your answer
I intalled the last release of openHab synology package I found : 2.4.0.
I just reconnect it but I know that Tomorow it still not work anymore.
Only broker will be still online
OH v2.4 mqtt is broken and OH 2.4 homie support is broken. There are a lot of topics re this on the OH forum about this
OH 2.5 progressively improves on this and the milestone releases are stable but obviously not '‘final’ - I don’t know when 2.5 release is due but for any success with homie integration you should use the latest milestone - currently 2.5 M4, which is available as an online ‘in development’ install.
If you’re on 2.4 and don’t want to upgrade until 2.5 is formal and final then Homey (homie) MQTT integration is not viable.
OH 2.5M4 might still be troublesome - not sure - I’m not using this integration (although I am reasonably familiar with it)
There is a new milestone 5 just released with one more milestone 6 planned early Dec. They are transitioning from the Paho MQTT client to the HiveMQ client due to core issues with Paho.
Probably worth waiting for the release version as M5 still shows MQTT changes happening.
All values are retained on the broker, so you should be able to grab the value by subscribing to the ‘measure_battery’ topic.
The ‘actual’ state is the ‘last known value’ as set by the device driver. There’s no way to ask for an updated device capability value.
Most battery powered devices have a predefined wake-up setting (e.g. once per hour) to report the remaining battery power. In between these devices only communicate state changes.
