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.
I’m happy with our Soma Twists, except for the fact that “closed” in HA is down. I really want them to close up. It looks like this method does the same. Is there a way to modify this to close up?
Hi there
I own a set of smart shades2 and the connect.
Things have just ‘worked’ for a year or more but suddenly, Im getting 'cannot call service - time out ’ errors on the SOMA integration in HA.
Does anyone have a fix for this? Im trying to get MQTT implemented via soma ctl but no success so far
Thanks
For that sensor you created to read the battery of the Tilt 2, are you using the IP and MAC for the SOMA Connect or the Tilt 2 itself? If it’s the Tilt 2, is there anyway to get the IP and MAC of it in the SOMA app?
Edit: Figured it out for anyone that wants to set it up:
sensor:
- platform: rest
name: Enter entity name here
resource: "http://your_soma_connect_IP:3000/get_battery_level/xx:xx:xx:xx:xx:xx"
value_template: '{{value_json.battery_percentage}}'
unit_of_measurement: "%"
scan_interval: 300
Any plans to publish (or point me towards) sample automations/code for getting the Tilt 2 to open up/down a certain %, close, open full, etc. from Home Assistant?