Curl > json command

NotoriousBDG · January 11, 2018, 3:38pm

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.

Mariusthvdb · January 11, 2018, 3:48pm

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.

NotoriousBDG · January 11, 2018, 4:31pm

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.

Mariusthvdb · January 11, 2018, 4:37pm

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…

NotoriousBDG · January 11, 2018, 4:47pm

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.

Mariusthvdb · January 11, 2018, 4:51pm

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.

NotoriousBDG · January 11, 2018, 5:38pm

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

Mariusthvdb · January 11, 2018, 6:04pm

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…

NotoriousBDG · January 11, 2018, 8:56pm

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?

Mariusthvdb · January 11, 2018, 9:54pm

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

NotoriousBDG · January 11, 2018, 10:41pm

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?

Mariusthvdb · January 12, 2018, 5:40am

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.

Mariusthvdb · January 12, 2018, 6:58am

created a separate thread for the zwave-mqtt issue:

Mariusthvdb · January 26, 2018, 7:45am

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.

NotoriousBDG · January 26, 2018, 2:12pm

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.

Mariusthvdb · January 26, 2018, 3:39pm

…
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,

NotoriousBDG · January 26, 2018, 4:41pm

You can add more than one key to authorized_keys.

Paxy · April 22, 2018, 9:15am

Great job.
Can you share your configuration about gui customization. Reilly like how you manage to groups components.