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.”
I know you don’t personally handle support much any more, but I just wanted to get back to you since the new 2.3.3 update resulted in the exact same issue of the Tilt not charging after new firmware was applied. I’d chalk this up to a random bug if it happened for one Tilt device, but it happened for all 3 (a 4th one is permanently connected to a power source so it remained at 100%).
All devices are the Tilt 2S and were updated from firmware 2.3.1 to 2.3.3. As you can see from the graph below, as soon as the 2.3.3 update was applied, the batteries rapidly discharged over the course of two days. Only once I used the Smart shades app to send a restart command to each shade, the shades started charging again (as indicated by the increase at the very end of the graph). The area where data is missing is due to a problem connecting to Soma Connect after a Home Assistant restart, so, you can disregard that.
The most concerning issue about the bug is the rate of discharge - even if no solar panel were connected, such a rapid discharge wouldn’t be experienced.
That is really weird. But did the restart fix it? If so I think it may be a bug in the DFU process itself as a restart is usually part of booting the new version anyway. Power consumption after DFU is not something we really test for right now but I will add this to our process for the future. We do test each new version for power consumption but we usually do that by just flashing the new version over SWD.
The rapid decrease in voltage is a bit troubling - where would the device dump all that power over such a short amount of time? The only thing I can think of now is maybe the motor drive system gets powered on somehow and not turned off as it should be.
We’ve been very focused on the new hardware version coming out soon so I don’t think there will be firmware updates for the motors any time soon. Connect will likely get more updates in the coming months as we integrate the new motors though. Hopefully that won’t cause this issue again.
Using the Smart Shades app and issuing a restart command for each Tilt 2S (via the troubleshooting section) did indeed fix it - As you can see, they have been charging via Solar since then (Although, I should charge them via mains and then switch back to solar since it’ll take a while to charge them back up to 100% via Solar only):
I am just as perplexed as you as to what the power was being dumped towards. I haven’t taken a look at what is returned by the API, but do the shades report their firmware version that could be added to the device info section of Home Assistant? If anything, if/when a restart command were to be/is added to the API, it would allow for using an automation to send a restart command to any shades that had their firmware bumped.
Is there any info available about the new hardware that is being worked on? Curious to see what new product is in the works!
I just found out that this is not the first time this issue has been brought to our attention. And it was already investigated but seems to be difficult to reproduce. The person who did the investigation is on vacation right now so I can’t ask for specifics but I think we didn’t solve this for now and the workaround is to just restart the device if this happens. We can issue the restart commands from the app after the update automatically so this would be a slightly hacky solution in the future. But seeing that the current version is almost at the limit of what the nrf51 SOC we use can do we don’t plan on adding many new features to that version with updates. We can still add functionality using the Connect but the device itself will likely just receive fixes and security updates.
I can add the device firmware version info to the “/list_devices” resopnse no problem. But really I don’t think an automation for that would be necessary. This should only happen very rarely and if at all possible we will try to find a way to fix this with the next update.
The new version should go up on our web store later this week. This is a major upgrade with all new plastics and a much bigger motor. We went over all the customer feedback we had received in the years with the current motor and tried to fix everything we could. So the new device has a bigger motor that gives us a massive increase in torque and max speed. But it also means that we can now move at a greatly reduced noise when we don’t go for max speed. I have a few of the new motors set up in my own home and moving at roughly the same speed as the current motors they are almost totally silent. We also have a better encoder so we can position shades much more accurately. A new wall mount system to better adjust and remove the motor. Batteries are now 18650 (two cells) that the user can replace if they really want. With these new batteries we can get around 6 months of battery life (calculated with the current prototypes). Battery life will depend a lot on movements and speed though. 6 months is with maximum speed and 2 movements per day with an average weight shade about 1.5 m long. We also have a much better SOC (nrf52840) that gives us more memory and a newer SDK to work with. Matter support is one of the main reasons we moved to that chip. We have tested Matter already on our hardware successfully. Due to certification requirements we may not offer Matter in the first release but it will be possible to upgrade to Matter as soon as we get all the certifications. Both Matter and HomeKit will be built into the motors themselves now and no Connect will be required for that (again - might not be ready for the first release but update should enable that for everyone). The new SOC also has Zigbee support - not tested yet on our own hardware but that is also something that we can possibly offer in the future. Charging will now have a standard USB-C connector and we will still support solar panels as well as plug-in chargers. The USB interface also has USB 2 signaling and currently we have it set up as a MSD with log files when connected to a PC (we still need to see what else we could use the USB for). The new motor also has on-motor control via 4 touch sensitive pads. At first launch we will offer up/down/stop commands via those buttons but in the future we could maybe also add on-device setup for installation without the SOMA app. Behind the scenes I’ve tried to make use of components that are available from multiple sources to avoid shortages better and we’ve also tested other motors that fit the same case for more speed or more torque. We will start presales pretty soon and hope to have the first units in customer hands in about 6 weeks.
At this point we are still integrating all the functionality the current motor has and it seems that the new motor will do all the same things just better. We will have more sensors and more room for better onboard automations. One of the new things is also a new BLE based control protocol that should make direct BLE integrations much simpler. I think HA now supports sending BLE commands directly and that should make for a really nice integration for these motors for those who want to avoid hubs.
First of all, thank you for providing technical insights about the new product. Sounds like those extra features (i.e., touch sensitive pads to control the motor) will be of great use for those that have shorter windows - I personally have very tall windows so I’d have to climb to reach the device 
.
I’m not sure how others feel about it, but enabling zigbee support would be a killer feature. I currently have a pi zero acting as the connect device with the first two Tilt devices right next to it and the other two tilt devices directly one floor above - The issue that I run into sending commands via the local API is that sometimes the commands fail to execute, but I get around that by using catch nodes in node-red to keep trying until the command sticks. I’d imagine using zigbee to control the devices would decrease or even eliminate the problem.
Do you expect the existing solar panels to be reusable via a female DC to USB-C connector?
The on-motor controls are actually one of the most requested features. But I agree that in some cases they won’t be of much use. They don’t really add much cost or power consumption to the device so they are fine if just left unused. We may add a configuration value to disable the controls completely if anyone should run into issues with them (or to save a bit of power). With Matter you can use pretty much any Matter enabled button/switch to control the motors from wherever you want.
Zigbee would be awesome but I don’t have much experience with that yet. I feel like it may be necessary to make separate firmware images for Zigbee and the BLE/Thread versions. But I will do my best to fit everything into one image first. If we need to make different images for Zigbee and BLE I will do my best to make the update process smooth in both directions. I’ve played around with some devices that had these sparate images and they only allowed you to update to Zigbee but never back. I will also have to look into certification costs with Zigbee - just the BLE/Matter thing will be very expensive already. Adding Zigbee will likely add even more certification costs. There are already some pretty cheap Zigbee motors on the market so we have to calculate if it would make financial sense for us.
Thread/Matter will likely solve the range issue just as well as Zigbee. Both would run at 2.4 GHz on this SOC anyway and the difference is just the protocol itself. BLE also has a long range mode available in this chip. In our tests long range BLE easily covered even the largest concrete houses. The problem is long range BLE is not really supported on phones and the current Connect versions don’t seem to support it either. The newer ESP32 based Connect could probably be ported to to the C3 or S3 variants that should support BLE5 and maybe we could then do better range for Connect<->motor communications. But that is something I will have to look into. ESP32 should also get a Thread enabled version at some point and then it may make sense to just move all of our hub communications over to Thread. Especially since that will make use of the mesh capabilities in Thread and expand range through any standard Thread device.
We use the same solar panel (just new plastics and a new cable) so it should work if you find such an adapter. It would be super simple to just replace the cable for the panel as well. If you have any experience with soldering you can do it in like 2 minutes.
We, I mean SOMA, have now started shipping the Smart Shades 3. I have tested Matter, HomeKit and Zigbee and they all work on this new platform. Certifications and testing for each of these will take some time and as far as I can see right now there is no way to support a combination of protocols concurrently. But my idea is to use the secure bootloader and DFU features to let the user select which system they need and an update will bring the correct radio drivers and software. We will have to iron out details on how this would work safely and provide users with a way back if they happen to update into a protocol version they can’t really use. But I’m sure we’ll find a way.
The new motors have been running non-stop in testing for months now and have had no issues so far. Battery life is up to 6 months and with the solar panel it should easily get through the darkest winters.
I still have to update the HA integration as that seems to have a weird way to rad the battery level at the moment. But that should not take more than a few days.
I wish HA (and all the other home automation system including Matter) would have better support for window covers though. For example there seems to be no way of specifying the speed a motor should use to open the shades right now. In our own app we can set a different speed for each movement. So you can have a slow and silent opening in the morning but you can also manually command the motor to move at full speed if you want to just look out the window. I’m sure there are way to work around this but this seems like something that people other than me would use if it were easy to use.
Since I’m still very actively working on this version any feature requests from the community here are more than welcome.
Hi there, I wondered if you have any idea when the Soma Smart Shades 3 will be available in Australia? I contact one of the companies who supplied the Smart Shades 2 but they weren’t able to tell me.
Thanks 
Hi, we are currently ramping up production and trying to catch up with all the preorders. We have an order from an Australian reseller but we do not have a solid date for when we ship that yet. Unofficially we now have all the materials stocked and I’m spending every day building motors at full speed. I hope to have enough stock to send out the Australian order in two to three weeks. Sorry about this taking so long but it will be worth the wait.
No worries, thanks for getting back to me. Do you mind telling me who the supplier is? I might contact them directly to get to the front of the line 
