I just wanted to let anyone interested in SOMA integration that a PR currently exists to add support to Home Assistant core. Certainly one to watch!
Iāve been using a generic roller blind motor which is controlled by IR so via my Broadlink for a while. However, the torque on it is pretty poor and half the time it fails so Iām looking to upgrade.
Are the Soma parts I need really Ā£100+ though??
Thanks
Hi,
This is Tiit - Iām writing the pull request right now for the core integration of Soma Connect. Iām one of the founders of Soma so any feature requests and questions can be directed at me.
The integration will only work with a Soma Connect on a separate Raspberry Pi for now. But we have released the image for free so all you need to run it is a Pi and an SD card. So no need to by the Connect from us any more if you can write your own image to a Pi. You would still need to buy the shades and they are indeed over Ā£100.
This integration will work using an open HTTP API we made for the Connect so it should be very fast compared to all the other solutions available right now. Well under 1 s for most cases for a single device. For multiple devices we donāt try to connect all at once any more like we do with the app. The Connect has a pool of requests and will try to push these out as fast as it can by opening a new connection for each request. This means that with many devices commanded at the same time there will be a slight offset in the time they receive the commands. But we have tried to optimize this to be as small as possible so that shades that are side by side move relatively at the same time.
Good evening everyone!
I come bearing good news: I now have this running on node 10.15.2 on Debian Buster, so no more relying on Node V8!
Steps I performed to get this working:
1 - Installation of packages
apt install sudo git net-tools curl apt-transport-https gnupg gnupg2 gnupg1 python3 python3-venv python3-pip libffi-dev libssl-dev bluetooth bluez libbluetooth-dev libudev-dev nodejs npm
2 - Change to /tmp and fetch the soma-ctrl project
cd /tmp
git clone https://github.com/andersonshatch/soma-ctrl.git
cd soma-ctrl
3 - edit package-lock.json
to reference updated, community-supported versions of the bluetooth-hci-socket and noble packages:
nano package-lock.json
- Find ābluetooth-hci-socketā and remove everything for that section. Replace with:
"@abandonware/bluetooth-hci-socket": {
"version": "0.5.3-1",
"resolved": "https://registry.npmjs.org/@abandonware/bluetooth-hci-socket/-/bluetooth-hci-socket-0.5.3-1.tgz",
"integrity": "sha512-NzLRq7mjAmvLDRA0E5hvCRtsuV0tq5fbUFxLxSmakRu9K4VM6u7P+3PvAkcylX3CEq0BY9Wwe3KXiMrQBjbMhg==",
"optional": true,
"requires": {
"debug": "^4.1.0",
"nan": "^2.10.0",
"node-pre-gyp": "^0.12.0",
"usb": "^1.1.0"
}
},
- Find ānobleā and remove everything for that section. Replace with:
"@abandonware/noble": {
"version": "1.9.2-1",
"resolved": "https://registry.npmjs.org/@abandonware/noble/-/noble-1.9.2-1.tgz",
"integrity": "sha512-M6NTjC+ZrMo/TuTRw0JNztiBjzMWcDPKx06MT1PEIwf+Lh+qeTCpRzsruWfrxEhssM77+8OaDaGsxYMIB1yAkw==",
"requires": {
"@abandonware/bluetooth-hci-socket": "^0.5.3-1",
"bplist-parser": "0.1.1",
"debug": "^4.1.0",
"xpc-connection": "~0.1.4"
}
},
4 - edit index.js
to reference @abandonware/noble:
nano index.js
Replace:
const noble = require('noble');
With:
const noble = require('@abandonware/noble');
5 - edit package.json
to reference @abandonware/noble:
nano package.json
Replace:
"noble": "^1.9.2-1",;
With:
"@abandonware/noble": "^1.9.2-1",
6 - Install the modified package:
npm install --unsafe-perm -g
7 - Launch with your usual launch parameters.
Hereās mine for example:
somactrl --mqtt-url mqtt://URL -u USER -p PASS
At some point in the future I will test this with Node 12.
Yes, each unit Ā£129, there are discounts for more than one unit though. They move relatively slowly, but they do work and the soma-ctrl project is reliable.
The Soma Connect integration I linked earlier and that the developer has kindly commented about requires the additional Soma Connect unit at Ā£99 in addition, or a raspberry pi and their software image.
Edited to include the info Tiit provided earlier. I should read more before posting.
Hi Tiit!
Always great to see a product manufacturer involved in the community. Can you tell me if the integration you have created works via the internet, or is it operational over the local network?
I have a very strong preference for local control as cloud services come and go, and I donāt want to lose my smart blind integration should the worst happen to SOMA.
The integration is local. It uses a Raspberry Pi to run our hub software. This hub is the same one we sell so it also includes Alexa, Homekit and Google Home integrations and some of these do have cloud connections. But you can just firewall the device off from accessing the internet and it would still work locally for Homekit and Home Assistant. We are thinking of either ipen sourcing the hub software or enabling users to install it from our package repository alongside other software. We are a bit hesitant at the moment due to support and possible liability issues.
I would be very interested in any of those outcomes. Thanks for getting back to me so quickly!
I came here because Iāve been having some new issues with the soma-ctrl
library, but I see that thereās possibly a new solution in the works! Thatās exciting. In the mean time, hereās whatās been happening.
I was using soma-ctrl
successfully for several weeks, and it was rock solid. Then a friend was staying over and paired the controller with his phone for a week. I paired it with the Raspberry pi again after he left, and now I canāt go more than about 24 hours without the Bluetooth connection getting dropped and having to restart soma-ctrl
to get it to connect again.
Right now Iāve got a cron job that restarts it every 6 hours, which should keep it running, but this is kind of annoying especially since it was working so well before! Is there anything I can do to make the bluetooth connection more stable?
Same here, unfortunately. I have long had an extra HTTP endpoint in there to quit soma-ctrl and then it will get restarted by systemd. I now have an automation in home-assistant to call this endpoint when a blind device has been unavailable for more than a few minutes. It gets triggered roughly once a day.
This quit endpoint is now in 2.0.0 which was released earlier this week. Had to be a major release as it drops support for older versions of node, not really representative of any major changes otherwise.
As for why this is happening now, Iād love to know, Iāve gone back to older versions of soma-ctrl to see if that made any difference, and it didnāt. One thing Iāve noticed is soma-ctrl seems to only be able to stay connected to a device for about 15 seconds now, when it used to go for well over a minute. Have yet to try rolling back some OS updates in case the bluetooth stack changed for the worse.
Hi Tilt,
I am a happy owner of 4 Soma shade controllers and a Soma Connect. Iāve had the controllers for almost 2 years and I received one of your first Connects. I am now using Home Assistant. I am having trouble getting the Connect to interface with Home Assistant. I am trying to use the Soma integration through the UI. It asks for the host and defaults to port 3000. When I try to connect it comes up with connection aborted each time. I have tried http:\IP_address and just the IP_address. Neither works.
Is there a different port I should be using? Also, should I be re-imaging the SD card on the connect to a later image? Would that help?
thanks
Hi John,
You can test if the API thing even works by just using curl or a web browser. Try for example: http://192.168.0.102:3000/list_devices (change the IP) and you should see a JSON response if the Connect is correctly set up. There was an issue I stupidly caused with the API versions so the safest bet would be to just flash the newest FW image we provide right now. Once you see that it works from the browser it should work from HA as well. The integration is very simple at the moment so thereās not that many things that can go wrong.
Iām now working on adding some more stuff to that integration like battery level reading and hopefully speed control. What we are aiming for in our own app as well is to make the move requests from UI as fast as possible. But that will be noisy. So we also try to make all the programmed moves (sunrise for example) as slow and silent as possible. Right now I can get it to move so slowly that it can be used for āsoftā wakeup routines where the shades rise slowly over tens of minutes.
Currently my soma blinds always stop after 2 minutes of running as (I understand) a safety mechanism.
Youāre saying it will run for 10ās of minutes, how does that work?
Any news on the slow/soft movement feature?
I see a v2 of the blind motors has been released with this feature amongst others - will any of these features make it to the v1 models?
Will the native integration report battery stats like Soma-Ctrl?
The soft/slow movement is implemented in our own app at the moment. I do want to add it to the API and also to HomeKit and other integrations soon. But we are kind of swamped dealing with meeting demand in this weird situation. Everything keeps getting delayed and that means the support load is huge explaining to people where their orders are and chasing down components for manufacturing.
All the features (except for the faster motor) will come to v1 as well. This is tested and working - the only thing we donāt have yet is the FW update functionality in the app. We are a pretty small shop so we have to prioritize what we want to do first. Since we had IFTTT and Samsung Smart Things almost ready before this we wanted to finish these. IFTTT is basically done now - just having some issues with their web still with uploading our branding images but this should be resolved soon. The next thing on the agenda is soma bug fixes for the app and for Connect and then FW update.
Iām not sure what you mean by the last question. Battery states are available from the API provided by Connect. I actually use them in my own setup with a separate REST sensor polling the API directly right now and it works perfectly. If by native integration you mean the Home Assistant plugin/integration I made then - yes. I actually had a pull request for just that but I implemented the battery level as a property or something and I believe that was not the right way to do that. Iām not really super good at Python or Home Assistant so Iām kind of hacking it as I go but since there seems to be a way for us to now do automatic discovery for the integration (Bonjour I think) I will try to update the Config Flow thing to skip the asking for IP step and at the same time get all the other new features in as well.
Great response, thank you!
Hi Tiit,
I really love the blind controllers. I have 4 of them. I am a little disappoint that the battery percentage isnāt implemented in the addon yet. I am curious if there is a way to explain the REST call you have and translate that to Home Assistant? It and updating the controllers are the only reasons I use the app anymore.
Thanks. And great product.
Thank you for the kinds words and for using our product.
The main reason the battery level is not in the integration is actually just me. I only built this integration because it was Hacktoberfest and I was using Home Assistant already. But I never thought there would be many users actually using this besides me. So when I found that I needed battery level readings I just did that part in YAML and REST. This is what I actually use right now:
# Sensors
sensor:
- platform: rest
name: Livingroom 2 Shades Battery
resource: "http://192.168.1.125:3000/get_battery_level/c7:1b:cc:8f:6c:57"
value_template: '{{value_json.battery_level}}'
unit_of_measurement: mV
scan_interval: 300
It should be super easy to add this to the integration if anyone wants to do that. The battery level reading command is even implemented in the pysoma wrapper already so you wouldnāt even need to do anything special with that. The main reason I didnāt add it was that I didnāt know how that battery level should be presented to HA. I think now that it probably should be a separate sensor exposed for each motor device but Iām still not sure. I think I tried exposing the battery level as an attribute to the shade device but ran into some problems. Iām really not an expert on Python on HA.
I do plan on installing the HA development environment again at some point to add some new features that we have now in the devices. And at that point I could also do the battery thing. But at the rate itās going right now that might happen in 2022ā¦
Thanks for the info. I got that part added in and now have a mV measurement of the battery. I am curious, do you know what that equates to in percentages? Is there a nice chart for that or something? Or is there some other rest command that gives the percentage?
While I am sometimes a coder (C, C++, C#, VB), I havenāt spent a ton of time in python so I will need to brush up and see if I can make the automation work for me.
I can look for the formula we use internally to get a percentage. But really itās only of average quality since a purely voltage based estimation doesnāt work too well for these Lithium batteries. Basically what we do is we know the full battery voltage (ideally 4200 mV) and empty (I think we use 3500 mV or something) voltage and we do a linear scaling between those limits. This is not very accurate but it does kind of work for now. A better way would be to map the voltage values to known battery levels. Or better yet use a special āenergy countingā chip or some other fancy measurement device. If you just want a rough estimate just use the simple scaled voltage for now.