I am using mosquitto linked to the MQTT binding in Openhab 4
I have a smart electricity meter which is connected to my mosquitto server.
The meter sends “live” consumption data every 5 seconds (I will call this packet 1), and once per minute, it sends a different packet, containing 4 data points.
This is packet 1:
(0)timestamp=2025-07-06T00:09:10
(1)1.7.0=858
(2)2.7.0=0
(3)1.8.0=10787771
(4)2.8.0=26926
(5)31.7.0=2.47
(6)51.7.0=0.76
(7)71.7.0=1.18
(8)32.7.0=238
(9)52.7.0=238
(10)72.7.0=238
(11)16.7.0=858
(12)uptime=0000:12:34:35
The problem I have is that when packet 2 arrives, all my items linked to packet 1 are set to null.
This destroys my homepage electricity generation dashboard for 5 seconds every minute.
The null values are not persisted, so my charts are still good, but the live dashboards look terrible.
Example in logs:
2025-07-06 00:09:05.522 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘SS_Smartmeter_Total_Export’ changed from 26926 Wh to NULL
2025-07-06 00:09:05.523 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘SS_Smartmeter_Consumed_Total’ changed from 10787768 Wh to NULL
2025-07-06 00:09:10.533 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘SS_Smartmeter_Total_Export’ changed from NULL to 26926 Wh
2025-07-06 00:09:10.534 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘SS_Smartmeter_Consumed_Total’ changed from NULL to 10787770 Wh
MQTT Explorer basically shows the same thing.
So, my question: Is it possible with some kind of config change in mosquitto or OH to force persist the previous data point for ~20 seconds instead of setting it to null?
Not sure if relevant to you, but I extract different temperature readings from the same state topic. The shelly device sends the same MQTT JSON message for the heartbeat and the 4 thermocouples. The temperatures do not update to null if the parameter is missing. Code;
- id: Furnace_Return_Air
channelTypeUID: mqtt:number
label: Shelly Furnace Return Air Temperature
configuration:
stateTopic: shellyplusuni-8c4f00a6cbec/events/rpc
transformationPattern:
- JSONPATH:$.params['temperature:100'].tF
unit: °F
- id: Furnace_Upstairs_Vent
channelTypeUID: mqtt:number
label: Shelly Furnace Upstairs Vent Temperature
configuration:
stateTopic: shellyplusuni-8c4f00a6cbec/events/rpc
transformationPattern:
- JSONPATH:$.params['temperature:103'].tF
unit: °F
etc.
Example State topic {"src":"shellyplusuni-8c4f00a6cbec","dst":"shellyplusuni-8c4f00a6cbec/events","method":"NotifyStatus","params":{"ts":1751813051.80,"temperature:100":{"tC":21.83,"tF":71.29}}}
This rapidly exceeded my knowledge What I also don’t understand is why the channel would go null if the other message did not contain ‘1.7.0’, like you asked originally, so am in the same boat.
I don’t know if this makes sense in your case but is there a section visible in MQTT explorer that shows the topic directly (maybe A4CF12E00000_1-7-0?) (and does it go null with the second message)? I generally use generic Mqtt things, not the HA configs, even if they are available. I don’t know it would make a difference.
Hi,
2 suggested solutions:
You can work with state filters in the profile !=NULL
or you can disable autoconfiguration for HA in MQTT. In this case, I prefer Generic MQTT Thing
I see that both you and tschetan are suggesting to go generic.
I already have loads of items added as generic (it’s a necessary evil to use zwave-js-ui), but this smartmeter device worked so well with ha-discovery I figured it was not necessary.
Thanks for your advice.
Can you elaborate more on this point? I don’t understand where & how these state filters are configured. I am using the UI for all config in OH 4.3.4
A comment: That is not what I had expected. Maybe the device only publishes what is needed by the HA config when that option is set (and it shows why you have a problem). I expected a full topic (something starting with SHRDZM/Home/Home/sensor) so you could extract the individual items like suggested above. I have tested zw-js-ui with HA configs and that is how that app does it. I’m still using generic, but with the recent HA config upgrades there were no issues like before.
Hi,
There is a Channel_Links/Profile between Channel and Items. On this page, select “State Filter” and enter something other than NULL in the “Conditions” field.
I wasn’t sure, so I even checked beforehand to see if a binding was active. Wrong glasses? Glad you got it working anyway, and it’s working to your satisfaction.
Note that this is somewhat related to [mqtt.homeassistant] Temporarily unavailable homeassistant components are not handled correctly · Issue #13496 · openhab/openhab-addons · GitHub. Basically, some Home Assistant-defined components will treat empty string as “ignore this update” and others will treat it as “set to none.” But currently openHAB we’re not exactly mirroring how Home Assistant works, so you end up with situations like this. It’s on my todo list of MQTT things to fix, and when I do so I plan to make the functionality available on generic MQTT things as well - a robust configuration on what value(s) set the the channel to NULL, UNDEF, empty string (for string channels), or just get ignored. But don’t expect it to happen in the next month or two… I’ve got several other large projects in front of it.
By saying this, you are also confirming this issue is caused by the HomeAssistant discovery.
The recommendation from Bob and Tschetan to use generic MQTT device would probably work.
Anyway, thanks for the updates, it seems there are fixes in the pipeline and workarounds in the meantime.
What I also don’t understand is why the channel would go null if the other message did not contain ‘1.7.0’, like you asked originally, so am in the same boat.
Glad you got it working anyway, and it’s working to your satisfaction.