I only use Some for the tilt blinds, but recently Switchbot have released a really nice alternative, but it doesn’t integrate into Home Assistant nicely yet.
Google the Switchbot Blind Tilt motor. It’s a really nice retrofit design. For other blinds that use a chain and curtains there are several different options.
Personally, once the Switchbot Blind Tilt is integrated to Home Assistant, I am changing over to that as you can keep Manila control as well as automatic control. 8 got a couple from the Kickstarter
I have two tilts if you need someone to test. I am useless with code, but I could test them and give you results.
Have you considered maybe using the bluetooth directly and not relying on the somewhat flakey connect?
I’ve considered the Bluetooth option, especially now that Home Assistant’s built-in Bluetooth support has been improved, but this was sufficient for my needs. My SOMA Connect works fine, the integration just didn’t cope with connections dropping.
And thanks for the offer, but without a Tilt, I don’t even know where to start.
I am probably going to get rid of the SOMA TILT devices soon. The Switchbot Blind Tilt looks like a much better option, and support for that in Home Assistant is beign worked on to be used with the Switchbot Bluetooth integration, which is 100% local. I know the connect works mostly local, but whenever the SOMA Connect is turned on, it also connects to SOMA servers, which I do want to get rid of.
Yeah, the connect really likes reaching out to connect.somasmarthome.com - its by far one of the most frequently queried domains for my DNS server.
Otherwise it works pretty well, I skipped using the integration and just call it via rest commands:
One annoyance is mine slowly get out of calibration, even with a beaded chain.
rest_command:
move_soma:
url: "http://192.168.40.16:3000/set_shade_position/{{ mac }}/{{ amount }}?morning_mode={{ morning_mode }}"
move_soma_slow:
url: "http://192.168.40.16:3000/set_shade_position/{{ mac }}/{{ amount }}?morning_mode=1"
move_soma_fast:
url: "http://192.168.40.16:3000/set_shade_position/{{ mac }}/{{ amount }}"
move_soma_close:
url: "http://192.168.40.16:3000/close_shade/{{ mac }}/{{ amount }}"
move_soma_open:
url: "http://192.168.40.16:3000/open_shade/{{ mac }}/{{ amount }}"
move_soma_stop:
url: "http://192.168.40.16:3000/stop_shade/{{ mac }}/{{ amount }}"
I’d like to know why the SOMA connect is reaching out to their server though.
SOMA have no way of disabling data collection in their software, and the REST API runs all locally.
It makes no sense for it to be phoning home all the time
It’s to enable Alexa and Google support. I disabled it by SSH’ing into the SOMA Connect and adding an entry to /etc/hosts to point connect.somasmarthome.com to 127.0.0.1. 
2 Likes
I never found the Google support reliable using linking direct to SOMA. Not sure what Alexa is like.
Still, it does a lot more communication than what is expected for a device that should only be talking to a server for a voice assistant command.
Is there anything that can be done to get better reporting back of the position of the shades to Home Assistant?
I’ve found that in colder months, about 1/2 of my shades (I have 6) struggle to open fully on the first command. They make it up 1/4-1/2 of the way, but then just stop for some reason. All three integrations into HA report those shades are at 100% open, but they’re physically not. I’ve tried the native HA integration, the Homekit controller version, and also this version from HACS, but they all report the same information - 100% open when they’re not.
For these shades that get stuck, I have to either ask them again to open fully or force them to close (when at 9x%) first before requesting them to open again.
I’d like to build some sort of automation to help solve this, but if it’s reporting as fully open, HA has no way to know they did not complete the original requested task. I’m curious if others have seen this and how they have solved it. And also, which method most are using for control.
I’ll see if I can tweak my add-on to be more accurate. Should have some time over the next few days, hopefully.
1 Like
This should be much improved in the latest version my custom add-on (v2023.3.1 released on 10 March 2023 AEST).
Keep in mind that it can still take SOMA Connect anywhere up to 30 seconds to notice if a shade isn’t moving or has stopped. However, the add-on now checks shade positions far more actively so it should usually only be a few seconds delayed, hopefully.
Let me know if this works for you.
Thanks! Will try it out and report back.
Also, I’ve currently got all three integrations connected to HA as I was testing. Any reason to believe that could cause any conflicts or issues? I’d like to switch to yours and will disable the others once I update my automations.
There should be no conflict, but depending on the number of shades you have, you may be overwhelming your SOMA Connect. Especially if it’s one of the original Raspberry Pi 3+ ones. Narrowing it down to a single integration would be good, once you find one you like. 
Got it. I disabled the others and only enabled the one @Djelibeybi just updated.
Unfortunately, it’s still not reporting the correct status for me on the stubborn shades. I have one that only went up 3% with the open command via HA. HA shows it 100% open, but the Soma native app (outside of HA) shows 3% open, which matches the actual state. The workaround is to close it via the native app and then reopen it. However, since HA thinks it’s fully open I have no way to automate this workaround reliably.
Please let me know if there is any info or logs I can grab that would show any helpful information as to why it’s not reporting correctly.
I’ve released 2023.3.2b1 as a preview via HACS which has a lot of debug log messages. To enable debug logging, add this to your configuration.yaml file:
logger:
default: info
logs:
custom_components.soma_connect: debug
If you already have a logger configuration stanza in your configuration.yaml, just add the last line.
Can you please install this and enable debug logging and then provide those logs via the GitHub discussion here: 2023.3.2b1 · Djelibeybi/hass-soma-connect · Discussion #22 · GitHub? We can then use GitHub for further discussion.
Don’t forget to restart Home Assistant after updating the custom component via HACS. If you have the latest version of Home Assistant that has the quick restart option, please use the full restart instead.
@Djelibeybi thanks again for your help so far on this issue. The latest firmware from Soma is helping as HA is now seeing the status within 30-90 seconds after they randomly stop.
I’m now trying to figure out the automation aspect so it’ll check to see if they full opened or closed and then resend the command until they do, but I’ve only partially figured it out. Here’s my new thread looking for some pointers on the automation aspect of this challenge. Sharing here in case anyone else has some suggestions. Thanks!
Try starting the automation on a device trigger of “opening” and then waiting for the device state of “closed” and if it doesn’t reach that state within however long it takes for a single run, then send the open command again.
It doesn’t appear the group that I created for the 6 shades exists as a “Device” so I was doing this off of the state, but “opening” did not work for this automation when triggering off the Shade group. So, it looks like this has to be done for each individual shade?
Is it possible to tie it off of the command to open all? I’m trying to figure out how to streamline it by the group without having to build 6 automations or maybe 6 choose options in the actions. But I still need to figure out how to get the single trigger for the group instead of 6 individual triggers.
I suggest starting with a single shade device just to test whether my idea works or not for your situation. Once that’s determined, then we can try and find the most efficient way to implement it across all your shades.
Do your devices show the “opening” state?
In my testing it looks like both the individual and grouped devices in HA only show “open” or “closed” for me and do not show “opening” or “closing.”