MQTT Binding - Ignore null values

wjones · July 5, 2025, 10:23pm

Hi All,

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

Packet 2:
(0)timestamp=2025-07-06T00:10:00
(1)1.8.1=4114262
(2)1.8.2=6673501
(3)2.8.1=10965
(4)2.8.2=15961

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?

Thanks in advance,
Will

apella12 · July 6, 2025, 2:52pm

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}}}

wjones · July 6, 2025, 8:03pm

Hi Bob,
I think this is pretty much what I have, the main exception is that my channels were auto discovered by homeassistant auto config.

This is one of my channels:

configuration:
  topics:
    - sensor/A4CF12E00000_1-7-0
  basetopic: homeassistant
bridgeUID: mqtt:broker:MiLightBroker
channels:
  - id: A4CF12E00000_1_7_0
    channelTypeUID: mqtt:ha-number
    label: 1.7.0
    configuration:
      component: sensor
      config:
        - "{\"name\":\"1.7.0\",\"dev_cla\":\"power\",\"stat_cla\":\"measurement\
          \",\"unit_of_meas\":\"W\",\"platform\":\"mqtt\",\"stat_t\":\"SHRDZM/Home\
          /Home/sensor\",\"uniq_id\":\"SHRDZM_A4CF12E00000_1-7-0\",\"val\
          _tpl\":\"{{value_json['1.7.0']}}\",\"dev\":{\"ids\":[\"SHRDZM-A4CF12E\
          E30EB\"],\"name\":\"SHRDZM-A4CF12E00000\",\"mf\":\"SHRDZM\",\"mdl\":\
          \"SMARTMETER\",\"sw\":\"1.3.1d-7e4f4b3965df36847d3e07109df64fb3\"}}"
      nodeid: ""
      objectid:
        - A4CF12E00000_1-7-0

I don’t understand the “config” part above, maybe there is something in there that defines what I am seeing.

apella12 · July 6, 2025, 8:56pm

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.

Tschetan · July 7, 2025, 6:22am

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

thingTypeUID: mqtt:topic
configuration: {}
channels:
  - id: SHRDZM_170
    channelTypeUID: mqtt:number
    label: SHRDZM_170
    description: ""
    configuration:
      stateTopic: SHRDZM/Home/Home/sensor
      transformationPattern:
        - JSONPATH:$.['1.7.0']
      unit: W
  - id: SHRDZM_180
    channelTypeUID: mqtt:number
    label: SHRDZM_180
    configuration:
      stateTopic: SHRDZM/Home/Home/sensor
      transformationPattern:
        - JSONPATH:$.['1.8.0']
      unit: W

The data probably comes in this form with MQTT

{
"timestamp":"2024-08-09T00:34:20",
"1.8.0":"10198444",
"2.8.0":"71",
"1.7.0":"363",
"2.7.0":"0",
"32.7.0":"234.50",
"52.7.0":"234.00",
"72.7.0":"235.10",
"31.7.0":"0.08",
"51.7.0":"0.94",
"71.7.0":"0.81",
"13.7.0":"85.00",
"16.7.0":"363",
"uptime":"0000:23:57:19"
}

wjones · July 7, 2025, 11:06am

Hi Bob, just to answer your questions:
In MQTT Explorer I see these 2 packets:

{
"timestamp":"2025-07-07T13:01:00",
"1.8.1":"4114262",
"1.8.2":"6705014",
"2.8.1":"10965",
"2.8.2":"15963",
"UTC":"2025-07-07T11:01:05"
}

{
"timestamp":"2025-07-07T13:01:15",
"1.7.0":"2408",
"2.7.0":"0",
"1.8.0":"10819306",
"2.8.0":"26928",
"31.7.0":"1.41",
"51.7.0":"8.37",
"71.7.0":"1.62",
"32.7.0":"236",
"52.7.0":"234",
"72.7.0":"235",
"16.7.0":"2408",
"uptime":"0002:01:26:40",
"UTC":"2025-07-07T11:01:20"
}

And the “comparing with previous message” feature in the tool looks like this (2 screenshots stuck together):

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.

I will post any updates as I progress.

Thanks for your help!

wjones · July 7, 2025, 11:10am

Hi Tschetan,

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

apella12 · July 7, 2025, 12:18pm

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.

Tschetan · July 7, 2025, 1:18pm

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.

wjones · July 7, 2025, 9:06pm

Yess.. that works!!

So, to summarise for those who may gain from my pain!

Install “Basic Profiles” from the add on store.
Go to your thing (in my case a smartmeter)
Under the channels tab, find the channel that you want to ignore null values
Click on the point under the channel
I now have the profile “State filter” that was missing without point 1 above
Under the conditions, enter “!=NULL”, this is case sensitive.
Save
Now this point ignores null values - Yay!

Thanks @Tschetan

Tschetan · July 8, 2025, 5:17am

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.

sihui · July 9, 2025, 5:34pm

Help is on the way

github.com/openhab/openhab-addons

[zwavejs] Initial contribution

main ← lsiepel:zwave_js

opened 06:45PM - 17 May 25 UTC

lsiepel

+32897 -0

This new binding makes use of the websocket service from ZWave-JS. Except for… the Bridge that connects to the mentioned server, all Things and Channels are created dynamically. Main advantage is that the binding does not need updates for new devices. So the support for new devices is not directly tied to the release cycle of openHAB. While ZUI is a great module, it is not a perfect fit with this concept. In some cases ZUI does not provide all the needed information so the binding does contain some assumptions. This seems to work pretty good, as tests show. This has been running for some months now on my and some other systems. With that in mind, many devices work as expected, but there is still room for improvement. This PR is here early to get feedback on the code and get some more testing traction. Hopefully we can merge this before the OH5 release. openHAB 5.0.x jar: https://1drv.ms/u/c/70ea7ac46bc61c73/Ef9Qdo-SkRBHnxtkhpPhm-UBF84AxlO8-4vEmT_0J-cOdw?e=zlHKb7 Closes: #16374

ccutrer · July 10, 2025, 6:47pm

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.