Shipping should be pretty quick. I just asked Christine and she said she is just finishing up orders from this Monday now and we should send out everything that was ordered before now on Monday. So there is a few days of delay but nothing major. If you still didn’t get a tracking number you can write to me or to our support (if you write to me I will ask support anyway since I personally don’t do the packing/shipping right now).
@ratsept I did get them a few days ago, sorry for the delay in updating!
I spoke to @balloob about doing a native BLE integration into HA and he advised against it because Bluetooth in HA is a mess. Now that I’ve gotten the shades & connect I’ve realized the latency isn’t as bad as I was thinking. However, it would be great to extend the existing integration to support Morning Mode and other functionality, I guess via custom services… Once Morning Mode & other mentioned fixes are available please let me know and I will take another look.
Will update once I get one of the devices installed on Sunday!
I think a native Bluetooth integration on the HA machine would also limit the installation a lot as BT range is what it is. And for myself for example the HA machine is installed in my network closet that is pretty much shielded so that would cut range dramatically.
I think a better solution in the short term would be to get this ESP32 BLE-to-MQTT bridge stable. In the longer term built in Thread/Zigbee/wifi look like better options.
Did anything come of this?
I just got whinged at, as the blinds are now going up at 07:00 with the lighter days (YAY!) - which is pretty noisy even a few rooms away - and need to find a way to slow it down/make it more quiet
I’ve been using the SOMA Connect on a Pi for a few years, quite happily without issue - so an option there with the HA integration/module would be preferable
EDIT: Should have waited until I’d finished reading the entire thread, can see it’s still pending.
I have the ESP32 thing also installed now. But it seems to have stability issues still. But I just tried and I can make it use morning mode through this thing. My colleague is working on the Connect right now but he is focusing on signal integrity and range issues right now. But I will remind him that we should add the morning mode API call as well.
Just checked back on this, I see morning mode has made it into SOMA connect now:
… although I think I might have to try downgrading again to the earlier version I was running, the device seems to drop off the wifi network a lot (previously it was pretty rock solid).
EDIT: I mounted the Pi SD image and edited wpa_supplicant.conf and set the correct country code (GB in my case, seems to ship/default to US) - I’d had this problem with other Raspbian based images previously.
Whilst I had it mounted, I also disabled wifi power saving in rc.local (iw wlan0 set power_save off) … so far, it seems to have resolved the issue.
Do you have any update on the HomeKit/Zigbee versions?
Thread really seems to be picking up traction, I hope the same applies to HA and possibly the next Soma shades?
Unfortunately I have no updates on this yet. Thread is definitely also something I’m looking into and I really hope with Thread we can completely phase out the SOMA Connect for most of our users. I have a feeling Thread support will start appearing outside of the Apple/HomeKit ecosystem as well and so Android users can also jump on that.
Thanks, I’m hoping thread can become a “one stop shop” for developers like yourself, one product that can work with HomeKit, HA, Google etc, it would make life much easier for everyone!
That would be a dream come true. The way the current market is kind of artificially broken apart is such a pain. I think it is mostly down to all the big players trying to tie people down into their ecosystems and keep them away from anything competing. So if Thread really does come with support in all the big ones this would mean the mix-and-match game would really take off.
@ratsept is there anyway to disable the battery level reporting? I have 19 soma shades 2 throughout my house with three connects (each connect controlling a specific set of shades) but with the battery device class it gets crazy when I look at my entity list in HA. Any help would be appreciated
I’m not exactly sure what you mean. Do you not want to see the battery entities appear at all? I’m honestly not sure. I’m by no means experienced with HA programming. I’m sure it would be possible. But I didn’t really see any other integration do that. For example all the Zigbee devices discovered will create a battery entity/sensor as well.
Or do you want to disable the actual BLE communication for this between Connect and the motors? That would be easier to do by just updating to the latest Connect firmware - we now parse battery levels (and also position data) from Advertising packets. So there is much less actual BLE traffic now.
You can hide the entities with Home Assistant in the Soma Connect integration.
Not sure what the issue is though. You just remove the battery entities from your dashboard, it really doesn’t matter if they are sitting in the state machine.
If you really want them gone, go to the Soma Connect integration, select the Battery entity and turn off Enable Entity. Simple. Not sure why you would want to as even with the Solar option there are times the battery will run down and need a manual top up.
Don’t bother about playing in the Soma Connect to work out how to disable the BLE, it is all or nothing. If you try to play with Soma Connect software you will lose the lot. Just disable it in Home Assistant…
@SgtHobNob
I don’t think Thread on it’s own will pick up any more traction than it has now as Thread is part of Matter. In fact the old ZigBee Alliance is now renamed to Connectivity Alliance and is basically merged with the Matter group now, which includes Apple amongst many other players. We may see Soma release ZigBee, but I think they may just stick to BLE on the blinds and maybe release Zigbee or maybe Matter compatibility on their Connect software. The Soma Connect can bridge into HomeKit, even though it is not officially compliant, it does work in HomeKit
Hi,
My SOMA shades have been working great for almost a year now. All of a sudden last week they stopped working in HA
So I updated the firmware on all the Shades, updated the Connect firmware, deleted the integration and readded it. It discovers my 4 shades, displays the names and battery levels but then anytime I ask the system to change positions I get this notice in the bottom left of my HA:
Failed to call service cover/close_cover. HTTPConnectionPool(host=‘192.168.20.241’, port=3000): Read timed out. (read timeout=5)
Any ideas what’s causing this??
@ratsept Hello from Australia! Firstly just wanted to say I’ve now got 6 Soma Smart Shade 2’s up and running and for the most part, they are great! Some of the issues I’ve been facing though seem to be specific to a lack of range of Bluetooth signal going out from my Raspberry Pi 4 running the Soma Connect image including but not limited to failed/timed-out calls and blinds not automating when they are supposed to. My residence is rather small, with the furthest Soma Shade at about 15 meters approx. away from the ethernet-connected Pi.
Short of buying, building and juggling multiple Soma Connects, is there a recommended way to extend range throughout the house? To my knowledge, unfortunately, no such thing as a generic Bluetooth repeater really exists.
Any help is hugely appreciated and thanks for the continued efforts to improve the Software, Firmware and HA Integration!
Hi @Irithor,
I’m glad to hear that you are mostly happy with the devices. And regarding the BLE range there really is not much you can do. Repeaters wouldn’t work because of the way Bluetooth protocol is set up. What could help theoretically would be better antennae and amplifiers. But that is not really practical for the low powered devices Smart Shades are. Currently it should be no problem to use multiple Connects with Home Assistant - just use the entities from whichever Connect is closer to the shade you want to control. We don’t recommend using more than one Connect if you use HomeKit for example as this could cause confusion is multiple hubs expose the same end device. Sometimes just repositioning the Connect slightly can also improve radio performance. The small antenna on the Connect doesn’t radiate well in all directions so just turning the Connect slightly or raising it higher can help. If you are using WiFi for the Connect switching over to wired Ethernet can also help.
All this is really part of the reason I really want to make a Zigbee or Z-Wave version as well. With mesh and better long range performance so many issues could be solved. And not having to make a hub specifically for just our devices would make my life so much easier as well. Matter/Thread also seems interesting in this same regard but right now it is a bit early to tell if that standard is going to stick. I don’t want to waste a load of time and resources making a Thread compatible model only for that thing to never really take off.
Hi looking at Soma’s as an option to automate a few Roman blinds. Has the quiet mode now been integrated into HA?
I don’t believe so - I get moaned at a few times a week, if you have a few of these at the same time it makes quite a noise.
Although less, now that the blinds are going up later, with the later sun rise - I have mine set to go up at sunrise, unless sunrise is earlier than 07:00, then it goes up at 07:00… this is what gets/got me moaned at
All in all, they are a reasonable solution for me - especially with the solar panels. Just a few niggles, such as lack of quiet mode. I think the controller has support for it now, last I checked I seem to recall something in the release notes, so it might be hack-able with a REST call, I just haven’t found the time to explore that/was hoping it would make it to the HA integration before I did.
Hi,
The HTTP API itself now supports “morning mode” but I’m not sure if anyone has updated the actual integration for Home Assistant yet. I’m actually not sure how that would even work as there is no standard way of doing that for the UI. You can see the description of how the API works here: https://support.somasmarthome.com/hc/en-us/articles/360026064234-HTTP-API
I think I could maybe do this (for the Hacktoberfest shirt ) if nobody else wants to try. But how do you think this should look like for HA? In the API it is set up so that for each motion command you can specify if you want this motion to happen fast or slow. Right now the SOMA integration creates cover entities and I’m not sure if there is a standard way to specify speed for those at all. If it’s not a standard thing then there are many options. I could maybe expose a switch entity for each cover that would set the speed to high/low. Depends a lot on how exactly this would be used through HA. Any input on this would be more than welcome.