MQTT Binding - Ignore null values

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

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

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.

This rapidly exceeded my knowledge :grimacing: 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

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

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!

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

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.

Yess.. that works!!

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

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

Thanks @Tschetan

1 Like

I wasn’t sure, so I even checked beforehand to see if a binding was active. Wrong glasses? :star_struck: Glad you got it working anyway, and it’s working to your satisfaction.

Help is on the way :blush:

1 Like