The input_boolean will turn on if the mqtt topic receives a payload of on or if the usage sensor changes to any value that’s above 0. The input_boolean will turn off if the mqtt topic receives a payload of off. The state of the sensor will be restored from recorder component when Home Assistant starts.
ha thats very useful!
could there be a follow up possible:
sensing the on-to-off state, or even the off state itself (several didnt even come-up to an on-state previously), force reading the state again somehow, maybe through the command line, and consequently setting the binary-sensor to the correct state (cause the states were fine, only the system wasn’t reporting correctly)
of course ill build in some notification, always like that
With the mqtt trigger, you can only look at the payload, which means you can’t see the state transition. You’d have to create an mqtt binary_sensor for that, and use it as the trigger in the automation if you wanted to trigger on state from: on and to: off.
Since you’re trying to get rid of polling with the command_line sensor, that’s not going to be simple to do. A workaround could be done by creating a script that checks the state via your hub’s API then call the Home Assistant API to change the input_boolean’s state.
but i have these, and use them already in the frontend. As a sort of backup to see whats going on. Because of these binaries i spotted the problems. the regular mqtt sensors are hidden…
and, happening as we speak:
while in fact there are not:
i am stumped.
That’s likely related to the retain flag not being set. The input_boolean and automation I sent before should work around the retain issue.
im heavily experimenting here now:
created your input_boolean and automation. Even when all is off, both automations are on, as is the input_boolean… named it tester check.
which of course is correct, since the sensor is on, and not off. this setup isnt yet testing the off state of the binary sensor, it is sensing the actual state of the sensor…
ive customized the binary state sensors to show last_changed so hopefully that will make debugging easier.
How can the retain flag not be set for all events? Would that be something the devs can adjust. I surely hope so, cause now i have to revert to the threshold binaries, (which of course still is better than the command line version) but they do rely on extra processor activity…
Sounds promising so far…
The retain flag has to be set by the publisher, which would be your z-wave hub. You’ll have to troubleshoot why the hub isn’t setting the retain flag. If you can get that working, the mqtt binary_sensor should start working as expected without having to do all of these workarounds.
i surely hope so, but somehow im not very confident its the publishers fault.
Ive just looked at my mqtt.log, and all states are set and received by Homeassistant correctly. Most of them 3 or 4 times in a row, a few of them on are than one occasion. At least im sure the publisher got through.
I can’t see whether this is done with a retain value, or would you know of a way to check that?
somehow that doesn’t get through for all of them, while they are correctly defined.
You can verify the retain flag with mosquitto_sub. Retained messages will have r1 flag and non-retained messages will have r0 flag.
mosquitto_sub -h IPADDRESS -p 1883 -u USERNAME -P 'PASSWORD' -v -d -t '#'
Client CLIENTID received PUBLISH (d0, q0, r1, m0, 'TOPICNAME', ... (3 bytes))
TOPICNAME OFF
Client CLIENTID received PUBLISH (d0, q0, r0, m0, 'TOPICNAME', ... (126 bytes))
quite!
doing so reveals that the r1 flag is sent on all events, up to the moment a tradfri motion sensor kicks in, and all subsequent events are sent with the r0 flag…
How this is possible other than being accidental? This quite amazing.
i can’t see the local tradfri sensor affecting the zwave hub at all…
That’s very odd. I have no idea what could be causing that because they shouldn’t be related. If you disable the component that’s sending Tradfri events via mqtt, does the problem stop?
well i am not sure what is sending in the first place…
To be honest i was surprised to see it occur in the mqtt log at all.
That being said, thinking back, i realize at about the same time suddenly a new sensor appeared in the front-end. while i had the tradfri sensors already defined by their hardware name , sensor1, sensor2 etc etc, suddenly this came up with the name i gave the group in the trådfri app, being Hall.
So there are 2 logical sensors for the same hardware. nothing special i thought of it, until now of course.
this is the one:
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
after which all other events are sent with r0.
only a reboot of the zwave hub bought my binaries back and they still are, while i turned the sensor around so it doesn’t trigger.
the line: homeassistant/sensor/tradfri_motion_sensor_3_battery/config is unfamiliar to me, so will have to investigate further. I you have any thought how to proceed from here, id appreciate it, as ever!
Thanks,
Marius
Are you using my battery_alert package? That message looks like it could be coming from it.
It’s just a theory, but maybe it’s an issue with your z-wave hub where it decides to stop publishing with retain flag when any messages are sent from publishers other than itself?
I am!
And it keeps bugging me;-)
Interesting . Issues indeed started around the time I changed to your latest version using MQTT .
Still, it’s must also be device related, since I got a low battery message, and the sensors were still there (while the offending TRÅDFRI is still turned around )
have a look, i have four sensors, of which only one (nr 3) shows also with its friendly name:
hmm, maybe. though it would surprise me evenmore, since the hub doesn’t subscribe to anything, it only publishes. I couldn’t see how it would notice anything else going on in my HA system, other then a command_line switch now and then.
created a separate thread for the zwave-mqtt issue:
HI,
followed all of this Generating a new SSH key and adding it to the ssh-agent - GitHub Docs successfully.
up to the point of copying the authorized_keys to the root /resin-root, which i cant see .
the only root i can find to copy it to is the root i see when sftp’ng to my hassio.local with ssh credentials. There’s no /resin-data there.
Must be the wrong root i presume.
so, let me ask please, how to complete the final step of Debugging the Home Assistant Supervisor | Home Assistant Developer Docs then if one cant see this /resin-root to copy it to.
fyi, the sd-card is in the Pi3, and Hassio is still running.
Shutdown the pi, insert the sdcard into your pc, copy authorized_keys to the root of the drive, plug it back into your pi, then try to ssh using the key you generated.
1 Like
…
feeling rather silly here, then again, so many questions on this community about this, maybe your super simple guideline could be added to the documentation page…
i take it the public key is only for the 1 specific device one creates the key on? Couldn’t log in with the Mac Air (i had to use to read the sd card) but could login with the Macbook Pro i created the keys on… again, simple once you realize.
- could several keys be created , so i can logon from more than one device?
I did create the keys with a password, which i didn’t have to enter, it swept me right in the root… That, i don’t like, must check, what went wrong there.
Anyways, thanks,
You can add more than one key to authorized_keys.
1 Like
Great job.
Can you share your configuration about gui customization. Reilly like how you manage to groups components.