Well the ssh & web terminal addon you can install the mosquito tools package or there are HA services you can use. This is just the way it is when you run HA OS.
Yes, I agree it would be more native. My problem is that the native MQTT integration is not very flexible when I want to submit a command and then check for the status (and resubmit if it fails).
With a bash script it’s easier to loop.
The frustrating thing is that when you login using port 2222, the script works perfect as both command are available. But it seems that shell_command executes directly in HASSOS and it doesn’t have both commands available
Port 2222 access:
Linux a0d7b954-ssh 4.19.127-v8 #1 SMP PREEMPT Mon Oct 12 08:05:33 UTC 2020 aarch64 Linux
Port 22222 access:
Linux homeassistant 4.19.127-v8 #1 SMP PREEMPT Mon Oct 12 08:05:33 UTC 2020 aarch64 HassOS
Yes Ha OS doesn’t have the package as I said.
In what way do you find the HA Broker unreliable? It never misses a beat here for me and I publish to it from a couple of other systems…
The sssh addon maybe includes pub/sub commands now so you don’t have to publish - not sure.
Depending on what you are trying to do you can for instance write to a sensor directly using a token so maybe that is a solution but the HA container doesn’t have mosquito tools…
Sorry for not being clear. It’s not the broker that is not reliable, but the MQTT client not always handles my requests properly. While I do agree it’s a client issue, I’m trying to work around it.
Just wondering, it there a way that shell commands are executed in a different context, like for instance in the ssh addon context?
It will be running inside the home assistant container. If you run Portainer and execute the script in a console (of the container) you will see what commands are available.
Like I said before, you might be able to achieve what you want some other way… what exactly are you using this for? You could for example use a HA long lived token depending on exactly what you are trying to do. For example I was using an MQTT via mosquitto_pub and then a Mqtt sensor but I could switch to use a rest sensor with a long lived token to directly write to a sensor instead. There’s often multiple ways to skin a cat and end up with the same result but we need more info to see if this or something else is possible…
Thanks for pointing me to the rigth container, I was struggling there.
What I’m trying to do is to send a command to a BLE radiator valve. This TRV is (using BLE) controlled by an ESP32 running tasmota (which is the prox running MQTT).
As BLE is not the most reliable protocol it might need several attempts before the message gets through (and to get an answer).
My logic:
Send the command using mosquitto_pub
Verify that the message has been received by the BLE driver on the ESP32 using mosquitto_sub (and retry if required)
Wait for the answer using mosquitto_sub and retry in case the message got lost
This process works well on a regular Linux host and also when using the ssh login (in HA). So maybe I need to run some commands remotely using ssh, but obviously I need to figure out how persistent ssh keys are inside the container.
So why not try the mosquito services in HA?
Nothing will be persistent in a container - that’s not how containers work. Have you checked a console in the SSH & Web Terminal addon? You could probable use pub/sub in there? But I would definitely look at using the services instead…
There is no feedback mechanism, so I don’t know if the publish has indeed been processed.
The ESP can only handle one command at a time, so with above approach I “hope” that it takes less than 30 seconds to process the request. Most of the times it’s less than 5 seconds, but there are cases that it can take easily 45 seconds (or fails)
With my shell script I could easily submit, monitor, and optionally resubmit when required. (And, once a request has been processed, submit the next request without waiting the full 30 seconds.)
And yes, I’m working with the developer of the BLE component in Tasmota to make the handling internal to the ESP32 more robust, but I don’t want to put all my eggs in one basket.
Looks like I’ve found a solution:
I use a wrapper script that is called with the required script as a parameter
The wrapper script executes in ha os and submits the required script using ssh in hassioaddons/ssh
Thank’s a lot @YJB , with your help I was finally able to get it working… also, the ssh that runs in shell_command needs to be told to use it’s own host id_rsa private key, which I copied in /config/ssh/id_rsa … (error 255 otherwise). So without having to use your wrapper it now works fine like this:
pheeww ! what a mouthfullllll ! … why all this trouble ? = I’ve been running a standard Hassio on 192.168.1.50 (APU2E4) for years now, for my switches and whatnot’s, and I didn’t want to mess with it, it works right ? . I recently installed Hassio on another separate inexpensive APU2E4 at 192.168.1.35, to implement the addon Rhasspy voice command system, as a master and 3 satellites on Raspberry Pi zero w with the seed https://www.seeedstudio.com/ReSpeaker-2-Mics-Pi-HAT.html . This all worked great until @frenck sadly removed his nice and easy service: hassio.addon_stdin …
Thank’s for your help !
jrb