Rough idea would be 2021. I have the new version of SOC samples and I have a PCB for them right now. Also tested the sample code for HomeKit on that SOC. So I’m hoping to start at least samples and test units with HomeKit functionality around Christmas. So best case for new SOC hardware availability to the general consumer would be spring of 2021. The new SOC also has Zigbee built in so it would hopefully be just a software update for Zigbee after that. But as of now I haven’t even tried compiling the sample code for Zigbee on that platform. We’ve been really busy with fixing bugs and getting sales numbers up with the current versions. I hope to hire at least one if not two new people soon to take care of the marketing and sales side to free up some time for me to work on the new features. This thing has grown so much and we have so many new ideas and so little time to implement them. But at the same time it is really exciting that people actually like what we came up with and for the past few years we’ve been able to pay our whole team from just working on this product. It is still kind of scary too - we’ve actually started noticing our products everywhere now. Just walking down the street and seeing something you made on another persons window is such a surreal feeling.
Well done man kudos to you. Keep up the hard work !
@ratsept, thought I would ask you here as you are being very informative… I really want to deploy the soma devices across my entire home, but as many have suggested have concerns about BT range, so will probably wait for a mesh network version.
However, I am also deeply concerned about guests in our home just yanking on the blinds/curtains to open/close them. Can you confirm if a button is going to be added to open/close manually, and if a future version can track if somebody manually moves the blinds?
The BT range is an issue with larger homes indeed. And to make things worse right now we only support one SOMA Connect per customer. But this limit is for HomeKit and Alexa and the like. For Home Assistant and other API based integrations it wouldn’t be hard to set up multiple Connects. The main issue with HomeKit and multiple Connects for example is that there will be multiple devices generated for the same physical device. But for Home Assistant this wouldn’t be a big issue as you could just ignore the ones you don’t want to use and just control each shade through the Connect that you know is closer to that shade.
We are working on a new version that will be built around the newer Nordic SOC with many improvements including range. But due to demand we are focusing on built-in HomeKit first. The SOC itself will also support ZigBee and also BT mesh and BT long range. So that will likely take care of most of the range issues. But honestly I do look at support myself almost every day and range doesn’t seem to be a big issue. There is the occasional missed command when the device is very far away but mostly people seem to have homes small enough for range to not be a major issue.
Manually forcing the shade with the current versions would be next to impossible. The gearbox and motor put up so much resistance that you are very likely to actually snap the device of the wall before you move the shade. We do want to have manual controls and we actually had a touch sensitive area on the v1 devices. But we didn’t use that much due to issues with that getting accidentally activated by the shade itself as it went by for example. We are now planning to add a small battery powered BT button that you could “pair” with one or more shades and use that for local control. The button itself is easy enough to just source from Asia. And we can easily make the button tell the shade to move up and down and stop. But the big issue is this “pairing” - this will need a pretty complicated app to set up. And that is what is stopping us from releasing that button thing very soon. An even cooler feature would be to somehow detect when the user is tugging on the shade or the cord and make the motor move from that signal. But I can’t think of a good way to implement this without a crazy complicated design for the gear that grabs the chain. A big thing we always have to keep in mind with this product is the power use and anything like trying to use the motor itself to detect torque (impossible with this design but possible with direct drive motors for example) would drain the battery very quickly.
Thank you for taking the time to provide those details. I just ordered a shelly button to experiment with. Perhaps I can use those next to a shades with a press/hold to scroll up/down the blinds. testing to be done! 
Hi. Has any of this been implemented yet? I’m very interested in this integration.
I saw some activity on the integration on Github by community members over the holidays but I don’t think all of this was implemented yet. Some features will need an update to the SOMA Connect as well so these are definitely not there yet. Still planning on doing this but like I said before this is still just a plan - no actual work on this has begun on our side yet.
I’m not sure if anyone else is experiencing this but I have 6 Smartshades integrated into HA and with the latest version they don’t seem to work any more. I have a feeling this may be because someone added the battery reading into the integration and with many devices there are now too many requests being sent out too fast.
I’m just writing this here so if anyone else has the same issue they would know they are not alone. I think the fix for this would be to make Connect cache more and respond to API requests with the latest cached data instead of opening a new BLE connection for each request. This is something that we will have to do in SOMA. While we are working on this a good workaround would probably be to make the polling interval longer somehow.
I’ve got two shades setup and everything seems to be working.
I switched from the MQTT implementation to a soma connect because I thought it’d be better to have a more official support once I saw the integration in Home Assistant.
But the number of requests the soma sends out is crazy. By far the highest of any device on my network by a factor of 2.
Is there any major difference between the Soma Connect and the MQTT besides the obvious?
(this is over the last 24 hours)
By the way, the shades have been great and I’ve been using them daily for quite some time.
I just updated and HA shows them as constantly going from available to unavailable.
I think I am just going to roll back until this is fixed.
Can anyone comment on the speed, quality and reliability of the soma 2? I haven’t been too successful in finding an objective review. Thanks in advance!
Hi @moto2000,
I’ve had one unit for about 7 months now…
Speed: Good from my perspective. On my 110cm high blind it takes 17s to go up and 14s to go down.This is at full motor speed which can be a little loud if kids are sleeping in the next room so I normally lower the motor speed in favour of lower noise.
Quality: No complaints, the hardware seems pretty well built.
Reliability: The physical unit itself has been faultless. I use the provided solar panel in the window and the battery is almost always fully charged which is nice.
When I got it originally, the (iOS) app suffered from some crashing issues but these seem to have been resolved in an update as I’ve had nothing in the last few months. I’ve never had a problem connecting and controlling the unit via the app, that’s pretty solid.
I have had some issues with the onboard automations (one’s you set via the app). I had one to close the blinds at sunrise but this would only work intermittently. I’ve since switched to closing them at 4am every day and not had a problem since.
As for Soma Connect and the integration with Home Assistant, it’s been very hit and miss for me. I’ve tried 2 different Pis in 3 different places in the house and still I find on many occasions that my Home Assistant automations have failed or that the device is unavailable. Your mileage may vary of course.
The HA integration aside I’d be happy to recommend. But, if the integration is important to you (as it is for me) then I’m not sure. As above though, maybe it just my house setup that’s a problem
I’m currently working on using an ESP32 as a bridge between the Soma device and MQTT. If I can get that working and stable then I’ll be happy.
Thank you for the thorough review! Very helpful and informative!
@ratsept Two questions for you:
- Could you add Morning Mode to the HTTP API? If you did that, I could extend the integration somehow.
- How would you feel about documenting the Bluetooth protocol you are using? If you did that, I could probably write a native Bluetooth based integration for Home Assistant.
Thinking about ordering 9 (!) Just ordered 5 for my new apartment, will order more once I know they work with my setup. My preference would be if the devices spoke native MQTT over WiFi but you can’t get everything you want in live 
. Let me know if the ZigBee/native HomeKit models are coming out very soon. If so, I might wait for them (also happy to help beta test them!!)
- Morning Mode is being added to the API as we speak. I hope we can have this all tested and ready for release soon. But since it is likely to be bundled with other fixes and additions I can’t say for sure exactly when we can release that.
- We have that protocol somewhat documented already. We haven’t shared it publicly but if you would like to take on that direct integration let me know and I can share the documentation with you privately.
We would also prefer native WiFI but so far we have not found a way to make that viable on a battery powered device. We can kind of make it work if we don’t keep the connection open all the time but that means that there will a long delay from any action before it reaches the motor. And I don’t think we want to move forward with that kind of “half-broken” solution. We are eagerly waiting for the new CHIP alliance/protocol. I kind of expect that to have support for IP based connection over Thread and hopefully routers and hubs will then start supporting it as well. Meaning that we could have a Thread device (low power) and still do direct MQTT with compatible routers.
I’ve been working on another (albeit unofficial) inegration route that shows promise. This is using an ESP32 to act as a bridge between BLE and MQTT.
Using an open source project called esp32-ble2mqtt and off the back of the work done for the soma-ctrl project I’ve been able to integrate my Soma blind unit into Home Assistant using just an ESP32. So far I can:
- Get the battery level.
- Get availability (connected status).
- Get current position.
- Set the position.
- Stop the blind.
The good:
- Only an ESP32 is required, no need to run a separate Raspberry Pi with a full Linux OS.
- All open source so tinkering and troubleshooting is possible.
The bad:
- Around every 5 minutes the ESP errors and the BLE connection is cut. The ESP automatically reconnects but the blind is unavailable for 5-10 seconds each time.
- Around once a day the ESP doesn’t reconnect after one of these errors and becomes un-responsive. After this, a restart of the ESP is required. < By plugging the ESP into a smart switch I can automate this reboot. Incredibly hacky but this is what Home Automation is for right?
Hopefully, with a bit of digging and potentially some help from the esp-ble2mqtt developer these issues might be solvable.
The unknown:
- I’m not sure how to set the motor speed. I certainly can’t see a BLE characteristic value that neatly matches the 60% I set in the app. This will need some digging.
-
I have noticed my Soma battery level is lower than I normally see it. This could be caused by the repeated re-connections, or perhaps it’s just that the weather here has been miserable for the last week! No sun, no solar charging.Edit: The battery has been fine since, I think it was just the clouds!
Just thought I’d mention it here in case anyone else is interested.
I’m not sure if I’m supposed to share my email here but if you contact support and tell them that I asked you to write to me from there I can get in direct contact with you. Or if you have the thing you are working on up on Github I could just add the speed control bit in a pull request for you. The way we are moving towards is not to make more BLE characteristics (since discovery is expensive) but rather build a kind of protocol over one (or a pair) of general purpose characteristics.
You’re fine to share your email here.
In that case contact me directly at [email protected]
I can share the documentation and I’m sure I can help with the code a bit as well if it is public and open source. If you want to work this into a commercial product we’d need to sign some NDA type of stuff before but it’s still possible to work something out.
How quickly is product shipping right now? Ordered last Thursday and still don’t have a tracking number.