Trädfri motion sensors stops mqtt retain value on Zwave hub - Home Assistant

Configuration Z-Wave
1

Continuing the discussion from Curl > json command:

thought it best to create a separate thread here, while @NotoriousBDG helped me sorting out this issue.

for all of you sharing my setup: HA and several Trädfri lights and sensors. One of the sensors suddenly appeared also with its friendly name, next to the device name, and causes issues in the mqtt traffic, more specifically causing the events publishes without the retain value.

this is the offender:

Client mosqsub|1165-core-ssh received PUBLISH (d0, q0, r1, m0, 'homeassistant/sensor/tradfri_motion_sensor_3_battery/config', ... (179 bytes))
homeassistant/sensor/tradfri_motion_sensor_3_battery/config {
  "device_class": "sensor",
  "name": "Hall motion sensor Battery",
  "state_topic": "homeassistant/sensor/tradfri_motion_sensor_3_battery/state",
  "unit_of_measurement": "%"
}
Client mosqsub|1165-core-ssh received PUBLISH (d0, q0, r1, m0, 'homeassistant/sensor/tradfri_motion_sensor_3_battery/state', ... (2 bytes))
homeassistant/sensor/tradfri_motion_sensor_3_battery/state 60

Cheers,
Marius

2

@NotoriousBDG

there’s this consideration also:

stop sending the R1 value is strange but shouldn’t be of a real issue while online and not rebooting the HA system shouldn’t it? It is only after a reboot of HA that the value is needed for re-reading, and r1 should be there.
The thing happening in my setup was even worse: after a trigger (now identified as the Tradfri sensor) all sensors relying on the state value went off. And didnt receive an update because the sender didnt resend.

Rebooting the HA didnt resolve this because the sender still didnt resend these states.

Only rebooting the Hub helped in this case.

So i think there are 2 issues at hand:

  • tradfri killing the r0 value and kicking the states out of the HA system completely, forcing the need for an immediate reboot of the Zwave hub. As far as i can analyse it now, this is caused by the Tradfri sensor being triggered.
  • a slightly less annoying effect of this setup, that after a HA reboot (several) state values aren’t read and populated. Havent been able to identify a cause for that, or if r0 or r1 is at hand. Seems it is just because the sensor is there, and being read (maybe because of your battery_levels package)

each and every time I start the mqtt logger i see the exact same series of events

all starting well r1 received for all published events. Also for Owntracks.
tradfri is read. r0 after that for each and every event. Also for Owntracks…

One would almost suspect a bug in the mosquitto handling of Home Assistant, being thrown-off the retain value.

just sayin…

Marius

3

Those 2 mqtt messages are from my battery_alert package at Howto create battery alert without creating a template for every device - #69 by NotoriousBDG, which just uses the native mqtt.publish service in Home Assistant to publish messages for battery levels.

That’s very strange. I’m not seeing the same behavior on my system. I have numerous devices publishing to the same Mosquitto instance including the battery_alert package and a few others that use the mqtt.publish service. It might be worth just disabling the battery_alert package and letting your system run for a bit to make sure it’s isolated to that package.

4

ive done so indeed, but havent had a chance to restart and reboot the Pi and hub (which is needed for the state’s to be populated after a restart of HA.

Will do so soon and report back!
Cheers,
MArius

5

@NotoriousBDG
hi,
taking out the package doesn’t make any difference. Ive even taken out the offending device entirely, also take-out the battery to be sure it can’t be seen anymore.
And what do you think: the sensor keeps coming up in the frontend , even with its friendly name… All references in my config files are scraped of this tradfri sensor, but yet… Rebooted the Tradrfir hub, the HA and host Pi, and several times the zwave hub.

It still shows up… Im am out of ideas how to delete this.
Could it be it is read from the mqtt logs somehow.?

strange thing is i think the command
mosquitto_sub -h 192.168.1.57 -p 1883 -u c0nnectit! -P stream_th0se_events -v -d -t '#'

loads the existing log somehow, always starting with r1. The existing log is always up to this tradfri sensor, which can’t be there anymore other than virtual. After that it runs fine, but with the r0 value.

Would it be of any effect to stop using these mqtt settings:

mqtt_statestreams:
  base_topic: homeassistant
include:
  domains:
    - homeassistant.setup
    - homeassistant.core
publish_attributes: true
publish_timestamps: true

and

mqtt:
  broker: !secret base_url
port: 1883
username: !secret mqtt_username
password: !secret mqtt_password

discovery: true
discovery_prefix: homeassistant

birth_message:
  topic: 'hass/status'
  payload: 'online'
  retain: 'true'
will_message:
  topic: 'hass/status'
  payload: 'offline'
  retain: 'true'

is there some kind of register or path we can browse to to find this:
homeassistant/sensor/tradfri_motion_sensor_3_battery/config

Client mosqsub|19111-core-ssh received PUBLISH (d0, q0, r1, m0, ‘homeassistant/sensor/tradfri_motion_sensor_3_battery/config’, … (179 bytes))
homeassistant/sensor/tradfri_motion_sensor_3_battery/config {
“device_class”: “sensor”,
“name”: “Hall motion sensor Battery”,
“state_topic”: “homeassistant/sensor/tradfri_motion_sensor_3_battery/state”,
“unit_of_measurement”: “%”

6

That’s because those messages were sent with the retain flag set. To get rid of a retained message, you have to send a null message with the retain flag set, then restart Home Assistant.

mosquitto_pub -h IPADDRESS -p 1883 -u USERNAME -P 'PASSWORD' -t "homeassistant/sensor/tradfri_motion_sensor_3_battery/config" -r -n
mosquitto_pub -h IPADDRESS -p 1883 -u USERNAME -P 'PASSWORD' -t "homeassistant/sensor/tradfri_motion_sensor_3_battery/state" -r -n
7

thank you!

i now see the line before the tradfri is also causing the r0 to allow after that:

Client mosqsub|1113-core-ssh received PUBLISH (d0, q0, r1, m0, ‘macaddress/triggi-prop/4a97255b/respok’, … (5 bytes))
macaddress/triggi-prop/4a97255b/respok false

would i need to do anything comparable there to? it is still r1, all others follow r0.

ive tried it with this,

mosquitto_pub -h 192.168.xxx.xxx -p 1883 -u username -P password -t “macaddress/triggi-prop/4a97255b/respok” -r -n
and restarted HA, but the error is still there… Ive also deleted the offender in the Iungo hub, so it can’t send anything anymore.
How to get rid of this in memory…

8

That should do it. Perhaps your hub is still sending messages to recreate it?

9

not sure what is happening, but the above worked, only to show the next line offender:slight_smile:
what on earth could be going on…

Client mosqsub|4171-core-ssh received PUBLISH (d0, q0, r1, m0, 'macaddress/bridge-zwave/b8d4960b/message', ... (38 bytes))
70:B3:D5:6F:31:F2/bridge-zwave/b8d4960b/message Press button on node to add to network
Client mosqsub|4171-core-ssh received PUBLISH (d0, q0, r1, m0, 'macaddress/bridge-zwave/b8d4960b/home_id', ... (3 bytes))
70:B3:D5:6F:31:F2/bridge-zwave/b8d4960b/home_id 784
Client mosqsub|4171-core-ssh received PUBLISH (d0, q0, r0, m0, 'macaddress/energy-dsmr4/538d72d9/T1', ... (8 bytes))
70:B3:D5:6F:31:F2/energy-dsmr4/538d72d9/T1 9900.831
Client mosqsub|4171-core-ssh received PUBLISH (d0, q0, r0, m0, 'macaddress/energy-dsmr4/538d72d9/L2Pimp', ... (5 bytes)

these are slightly different to set to null, because i can’t do it with the same procedure, resulting in this error:

Error: Both topic and message must be supplied.

Isnt there a way to flush the full mqtt memory n the mosquito broker and restart all over?

maybe this is important for debug: if i stop the hub sending with r1 , no mqtt event is shown on the log at all, other than

Client mosqsub|6085-core-ssh sending PINGREQ
Client mosqsub|6085-core-ssh received PINGRESP
Client mosqsub|6085-core-ssh sending PINGREQ
Client mosqsub|6085-core-ssh received PINGRESP

and consequently none of the sensors is updated with any value. Which is very odd, since before the hub had the option of enabling/disabling retain value, this didnt happen.

On the sending hub’s log, i can see all events being published. the mosquito log in Hassio add-on stays rather empty too.

Re-enabling the retain value in the hub immediately shows all events streaming in again, both on the add-on and the ssh mosquitto log , albeit with R0.

so much for a calm weekend…

Marius

10

When you start mosquitto_sub, it displays all stale retained messages by default then it starts displaying all new messages. Could it be that you’re seeing those stale retained messages first followed by new messages that don’t have the retain flag set? You can make mosquitto_sub stop showing those stale retained messages by adding a ‘-R’ switch.

mosquitto_sub -h IPADDRESS -p 1883 -u USERNAME -P 'PASSWORD' -v -d -R -t '#'

The easiest way is to uninstall and re-install the addon. You can restore the config, by using copy/paste.

Those are keepalive messages. They only show when you have debug logging enabled. That’s perfectly normal behavior.

It still sounds like an issue with your hub since you’re seeing messages sent without the retain flag.

11

That what i thought too, but unfortunately, theres no difference in result:

Client mosqsub|6950-core-ssh received PUBLISH (d0, q0, r1, m0, 'macaddress/sensormultilevel-zwave/18d91bde/sensors', ... (25 bytes))
Client mosqsub|6950-core-ssh received PUBLISH (d0, q0, r1, m0, 'macaddress/sensormultilevel-zwave/18d91bde/classes', ... (7 bytes))
Client mosqsub|6950-core-ssh received PUBLISH (d0, q0, r1, m0, 'macaddress/bridge-zwave/b8d4960b/node_count', ... (2 bytes))
Client mosqsub|6950-core-ssh received PUBLISH (d0, q0, r1, m0, 'macaddress/bridge-zwave/b8d4960b/message', ... (38 bytes))
Client mosqsub|6950-core-ssh received PUBLISH (d0, q0, r1, m0, 'macaddress/bridge-zwave/b8d4960b/home_id', ... (3 bytes))
Client mosqsub|6950-core-ssh received PUBLISH (d0, q0, r0, m0, 'macaddress/energy-dsmr4/538d72d9/T1', ... (8 bytes))
macaddress/energy-dsmr4/538d72d9/T1 9912.528
Client mosqsub|6950-core-ssh received PUBLISH (d0, q0, r0, m0, 'macaddress/energy-dsmr4/538d72d9/L1Pimp', ... (5 bytes))
macaddress/energy-dsmr4/538d72d9/L1Pimp 0.118
Client mosqsub|6950-core-ssh received PUBLISH (d0, q0, r0, m0, 'macaddress/energy-dsmr4/538d72d9/L2Pimp', ... (5 bytes))

etc etc

have tried that, without result sofar. maybe a reboot of both systems will change anything.

agree, will see what he dev’s say…

Thanks for your patience…

12

@NotoriousBDG
since your my to-go-to in matters of MQTT, please have look at Allow mqtt_statestream component the ability to include/exclude entities

because i can’t see why all events are published while i have no reference to mqtt state streams in my configuration file left… ?? Its a bit of a web sockets issue, regular max pending messages appearing, i believe to be originated from/caused by this Mqtt state stream.

Cheers,
Marius