Soma blind control via MQTT

mqtt
Tags: #<Tag:0x00007f203c609128>

#41

Is it possible to run Somactrl as a daemon? I have been trying but without success. But then I’m a total newbie to daemon/service… I wrote a shell script which calls Somactrl with the right args., as I don’t know how to pass on the arguments otherwise. But the system complains about the shebang #!usr/bin/env node in Somactrl, “no such file or directory”. When i run Somactrl from the command line it works fine though.

And another question. Sometimes my RISE-unit disconnect without reason (as I can understand it). When that happens, I would like Somactrl to make a new scan, once or twice maybe, to see if the unit is still there. Is that possible? Do I have to restart Somactrl to do that? Can I control that from homeassistant as an automation or should I do that in the service somehow?


#42

I managed to run Somactrl as a daemon/service. There was a link between node and nodejs that had to be installed first. Happy! Tell me if you want to know more about how.

Next thing to try to master is the rescanning.


#43

Sorry for the delayed response, been on some travel for work.
As you’ve discovered it is possible to have upstart/init.d start it, I should really put a quick script in the readme or github repo for others.

I’ve lately taken to using a custom version of soma-ctrl which has an extra web API endpoint that kills the process, so it then gets restarted by upstart and re-connects to all the devices.
This is hooked up to a REST command in home-assistant so I can just hit a button in lovelace to trigger it when a device is no longer responding.
Not sure whether to add this in to a release though, in reality there is something about the re-connect/error handling logic that needs improving. Most of the time when I need to use my reset button the device claims to be connected still, which it really shouldn’t – is that usually the case for everyone?


#44

I did it with systemd, not init.d, which is more modern as I understand it. I am new to both of them, so I didn’t really look into init.d. Went for the newer one - systemd.

For me, Somactrl gets restarted at reboot, not restart of HA. Maybe I will change that. I am now working on a script for restarting somactrl . (not using lovelace yet, I want to finish this project before I migrate) .

The connection problem for me is that somactrl is running but the device turns unavailable. When I restart somactrl, the device gets connected/available again. Later on, it turns unavailable again. When I started working with somactrl some while ago, I got a long list of messages in the putty-window saying ‘somactrl RISE114 connected +225s’ etc. Nowadays I only get this message once. Is that indicating something?


#45

Ah yeah, systemd was what I used too, I just couldn’t recall the name.
Just put together some quick steps for that on the wiki https://github.com/andersonshatch/soma-ctrl/wiki/Starting-automatically-with-systemd

I also put together a branch that will try re-connecting every 10 seconds when disconnected, perhaps you can try it out and let me know if this improves things?
The branch is named reconnect-interval, and instructions for using it are here.
If it’s still being problematic it’ll probably be best to move this to a GitHub issue instead.


#46

Starting automatically: great! I had to run sudo apt-get install nodejs npm to get the service to work, though, to get the misnaming or whatever the problem is for node and nodejs to get solved.

Reconnecting: I’ll try out the branch. But not sure about the last point, Run node index.js with your normal set of options. I don’t run node specifically when using soma-ctrl. I just run somactrl. So I don’t know what my normal set of opions is…
So I don’t run node index.js, I run somactrl with my normal set of options. Correct me if I am doing wrong.


#47

image

Got this error when running somactrl and then trying to maneuver the cover from HA.

There was enough time for the rescanning to occur (some minutes before I tried to maneuver from HA), but I didn’t get any messages that somactrl was scanning again.


#48

That error should be solved in version 1.3.0 and above I think; are you on an older version?
Regarding your usual options, I just mean anything you would normally put after somactrl, I.e. your mqtt URL.
So to try out the specific branch, you’d just run the same command and instead of somactrl ..mqtturl etc... you’d run node index.js ..mqtturl etc...


#49

I’m running version 1.3.0.

Next time I ran somactrl -normal options I didn’t get the same error.

Thanks for clearifying node/somactrl. Now I am running node index.js -normal options, has been up running for 30 min approx. The device is still connected, I can maneuver it from HA. But I cannot see any more scans of somactrl than the initial one.

image


#50

Now, contact with the device is lost. It shows unavailable in HA, and has been unavailable since 03 last night.

The branch of somactrl is still running, at least it looks like it in the Putty-window (which hasn’t changed at all since I posted last time). When I check with top -u pi, I cannot see it though. But I am not sure it should turn up there and I didn’t check top when I just started the program.

Edit: It shows up when I runtop -u pi. I just didn’t look for node, just for somactrl… My fault.

Edit2: In the system log I found this:
Feb 9 03:04:17 hassbian kernel: [488476.267714] Bluetooth: hci0 command 0x200d tx timeout


#51

Hmm, I think I messed up with what I pushed to that branch, I went to check and didn’t see anything different from the main branch, in fact it was a little outdated.
I think the jet lag is at fault; Sorry about that!
I’ve now pushed the changes to that branch for sure so it should repeatedly try reconnecting when disconnected (no re-scan), can you do another git pull and npm install and try it now?


#52

I’ll try again, no worries!

It’s running now. Could control the device from HA without error. So far so good.

Should I expect to see some output on in the command terminal, like “RISE114 connected”? Or is it fine with the 3-line output I posted before (soma* scanning, soma* connected RISE114, soma* stopping scan)

Would reconnecting solve the problem with the hci0 timeout? I’ve tried to find information on this timeout problem but no luck yet. I don’t understand what it means, really.


#53

The program ran for approximately 2h, then there was a timeout for hci0 and the device was disconnected (not sure what happened first).

syslog:

Feb 9 22:19:24 hassbian kernel: [557782.738374] Bluetooth: hci0 command 0x200d tx timeout

According to top, Node is still running.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29243 pi 20 0 8136 3304 2760 R 1.3 0.3 0:02.84 top
3211 pi 20 0 14988 7660 3476 S 0.0 0.8 0:05.14 sshd
3223 pi 20 0 16440 9160 3412 S 0.0 1.0 0:05.15 sshd
14481 pi 20 0 11576 4180 3416 S 0.0 0.4 0:01.93 sshd
15167 pi 20 0 95688 35492 21176 S 0.0 3.7 0:12.96 node

According to bluetoothctl, the BT-dongle (I use an RPi2 with a separate BT usb dongle) seems to be missing:

[bluetooth]# devices
No default controller available
[bluetooth]# list
[bluetooth]# paired-devices
No default controller available

My conclusions are:

  1. The source of the problem is the timeout of the dongle. I don’t think it is within somactrl. If anybody has any ideas were to start looking for the solution, plz tell me :slight_smile:
  2. To make somactrl more robust, it should handle such timeouts. I tried these things, in order:
    2.1 Restarting the bluetooth.service. Didn’t help.
    2.2 After that, stopping and restarting somactrl (branch). Didn’t help.
    2.3 After that, restarting homeassistent. Didn’t help.
    2.4 After that, restarting somactrl (branch) again. Worked! Device is back in HA.
    I think the two first steps are unneccessary. Next time the device disconnect, I will try only steps 2.3 and 2.4. I have created an automation that is triggered by the device disconnecting. Eventually, I will set the action to “restart homeassistant”, and then create another automation triggered by “start of homeassistant” to “start somactrl”. Or something similar. But it would be nicer if it was handled within somactrl…

Over


#54

Hmm, that actually has me thinking about my systemd script, it makes sense for the status of somactrl to be linked to the bluetooth service.
I’ve altered my script so that it comes up and goes down with the bluetooth service; furthermore, if you start somactrl when bluetooth is not running, it’ll start bluetooth for you.
Presumably there’s some way to have the bluetooth service restarted when your adapter re-appears.