This seems like working good.
Would it be possible to have trigger cards for when a specific number capability changed. Now there is only become greater / less than
There is also Value changed, but it doesn’t tell which value.
That trigger would be particularily useful for latitude/longitude changes to tigger GPS to address flows to update current address.
Also there is the Text changed, but now the question is which string capability, I have two in the configuration?
That is standard Homey logic.
Every numeric capability gets a higher/lower flow trigger generated.
But only main capabilities get default flow cards generated (value changed).
The app has two custom capabilities for generic values (measure_string, measure_number) wich such trigger cards. But also only for main capabilies. I think the trigger cards are coming up from these capabilities.
Ok, I’m using the measure_number for all numerics, since there is no standard capability for the number values I use. So yes, there are sub capabilities quite a few.
Hi! Thanks for the app!
Until now I’ve used it to create different MQTT devices. Mostly ESP32 stuff. And they are working. Now I decided to add a descoverable device. I "manually” published device properties to its topic. The device is discovered, but never gets update. In the MQTT Explorer looks like:
▼homie
▶deviceid
▼lightsensor
$homie = 3.0.1
$name = lightsensor
$nodes = light-sensor
$state = ready
▼light-sensor
$name = Ambient_Light_Sensor
$type = sensor
$properties = measure_luminance
▼measure_luminance = 12
$name = Luminance
$datatype = float
$unit = lx
$retained = true
$settable = false
In the Homey tools capability of the device is shown as:
{“measure_luminance”:{“stateTopic”:“homie/lightsensor/light-sensor”}}
But when I “manually" (with MQTT Explorer, for example) set the value for the homie/lightsensor/light-sensor/measure_luminance, in the device card it is not updated.
What am I doing wrong?
I want to acknowledge the work @RonnyW has done in maintaining the MQTT Hub. The community version has kept the project running for those who depend on it, and that deserves recognition. After I stepped away from Homey, continued maintenance became essential, and the community version has fulfilled that role.
I appreciate the effort taken to keep the project operational.
Thanks Ronny!
— Harrie
Thanks, Harrie. Yeah, it was a mixture of fun and work to dive into it 
Are you back at Homey Community?
Not really, just wanted to show appreciation for the work that’s been done.
I’m no longer active with Homey, but it’s great to see the project in good hands.
Hi all,
Over the past few days I ran into a strange issue with one of my CO₂ sensors that is forwarded from Homey to Home Assistant via the MQTT Hub app. The temperature and humidity sensors from the same device worked fine, but the CO₂ value never showed up in Home Assistant.
In the Home Assistant logs I noticed error messages related to the MQTT discovery payload for this sensor. The message indicated that the device_class was invalid. This was surprising, because another CO₂ sensor using the same device_class was still working correctly.
After some digging and Googling, I eventually published a corrected discovery payload manually using MQTT Explorer. As soon as I did that, the CO₂ entity was created immediately and everything started working again.
It turns out the root cause lies in how Home Assistant handles MQTT Discovery:
Existing entities continue to work, even if the discovery payload later becomes invalid.
New entities are rejected if the discovery payload contains errors.
The temperature and humidity entities for this CO₂ device already existed, so they kept working. The CO₂ entity did not exist (I probably deleted it myself accidentally during a recent cleanup), and because the discovery payload contained errors, Home Assistant refused to recreate it.
My first conclusion is that the MQTT Hub app on Homey is sending discovery payloads that do not fully comply with Home Assistant’s MQTT Discovery specifications. After manually publishing a correct discovery payload, the CO₂ sensor works normally again.
Below is a summary of the issues I believe I’m seeing based on the error messages in the HA log.
If this looks familiar, perhaps these points can be addressed in a future release of MQTT Hub?
1. Device class – CO₂
What MQTT Hub currently sends: device_class: “co2”
What Home Assistant expects: device_class: “carbon_dioxide”
Effect in Home Assistant: The CO₂ entity is not created. Home Assistant rejects the discovery payload.
Log message: Error about expected SensorDeviceClass.
2. Unit of measurement – temperature
What MQTT Hub currently sends: unit_of_measurement: “C”
What Home Assistant expects: unit_of_measurement: “°C”
Effect in Home Assistant: Discovery is rejected. Existing entities continue to work, but new ones are not created.
Log message: ValueError for temperature sensor.
3. Unit of measurement – particulate matter (PM) sensors
What MQTT Hub currently sends: unit_of_measurement: “ug/m”
What Home Assistant expects: unit_of_measurement: “µg/m³”
Effect in Home Assistant: Discovery is rejected. New entities are not created.
Log message: ValueError for PM sensor.
4. Numeric sensors sending null
What MQTT Hub currently sends: Payload “null” for sensors that must have a numeric value (e.g., voltage).
What Home Assistant expects: A number, or “unavailable” if the value is temporarily not available.
Effect in Home Assistant: Home Assistant logs errors and ignores the update.
Log message: “non numeric value: ‘null’”.
Hi All,
first: all best wishes for 2026!
So, my personal challenge.. I have a mqtt feed from an Ebusd with in the payload semicolon separated values. i tried something like (value) => (return value.split(‘;’)[0] ) but that does not work.
how should I handle this?
best regards,
{
“measure_temperature”: {
"capability": "measure_temperature", "stateTopic": "ebusd/vr_70/SensorData", "setTopic": "", "valueTemplate": "(value) => Number(value.split(';')[0])", "outputTemplate": "", "displayName": "Temperature"}
}
Thanks for your insights. I will take a look at it.
If I remember right, the device class is mappes inside the app. But I’m not sure how the unit is exported. Can you please check the units of your devices in Homey developer tools if they are correct/matching?
Does it work it the string is not escaped like this?
"valueTemplate": "(value) => Number(value.split(';')[0])",
not sure how these slashes came there, this is the config for the mqtt device. It does not work.
{
“measure_temperature”: {
“capability”: “measure_temperature”,
“stateTopic”: “ebusd/vr_70/SensorData”,
“setTopic”: “”,
“valueTemplate”: “(value) => Number(value.split(‘;’)[0])”,
“outputTemplate”: “”,
“displayName”: “Temperature”
}
}
I have to update the hint. This should be the correct syntax:
"valueTemplate": "(topic) => Number(topic.value.split(';')[0])",
hi Ronny,
thank you for you input. unfortunately it doesnt 
i’m thinking, it’s not a string. it seems to be “raw” output.
{
“measure_temperature”: {
"capability": "measure_temperature", "stateTopic": "ebusd/vr_70/SensorData", "setTopic": "", "valueTemplate": "(topic) => Number(topic.value.split(';')[0])", "outputTemplate": "", "displayName": "Temperature"}
}
Forgot the “return”
"valueTemplate": "(topic) => { return Number(topic.value.split(';')[0]); }",
hi Ronny,
jou made me thing on your “ditch the \[“ remark. I replaced all special characters and it works now. Seemed to be illegal characters copied from web-sources 
{
“measure_temperature”: {
"capability": "measure_temperature", "stateTopic": "ebusd/vr_70/SensorData", "setTopic": "", "valueTemplate": "(value) => Number(value.value.split(';')\[0\])", "outputTemplate": "", "displayName": "Temperature"}
}
What exactly do you want me to check?
The table below is what I find in the device section, but it does not state what units it uses.
Yes - at least partially.
But first to the device_class. I changed the mapping to use carbon_monoxide / carbon_dioxide based on HA sensor and HA binary_sensor definition.
Now to units…
The unit is based on the unit of your capability. If using measure_temperature, °C should be used (based on Homey capabilities). Coming in next update.
New test version 4.5.4:
@Merpster FYI and test.
Hi Ronny,
I looked a bit further and indeed I think this is a device specific issue that you cannot solve.
The errormessages on ‘C’ en ‘ug/m’ are only from the AWAIR Elements CO2 sensor that I use (next to MCOhome sensors) (Awair Element Luchtkwaliteitsmeter - Fijnstof, CO2, temperatuur, luchtvochtigheid | bol)
If I look in the Homey device I also see ‘C’ en ‘ug/m’ as units and also in the MQTT explorer these are passed on as ‘C’ en ‘ug/m’.
Homey screenshot:
MQTT Explorer Screenshot:
Maybe something for @Edwin_Biemond 
? (= the developer of the Homey Awair app)
