Can you please add the smart curtain robots #126
Comments
|
got this Curtain Rotot too. |
|
I Just bought one today, excited to gain control via home assistant |
|
mine have arrived today, does any fork was succesfully on integrating this device? |
|
@Majestic7979 if you enable debug logging for the integration you should get a log similar to: Send that over and I'll see if I can find a matching device with datapoints. I've started adding cover support here: |
i'll get that ASAP, and open an issue in your fork to make it work, thank you!! |
|
unfortunately, after add your repo on the hacs, I couldnt make it work, and the logs I get this:
|
I got this information by tuya developer tools, is usable? { |
|
@hiagocosta haven't seen your messages, sorry. I've updated my fork. You will need to download the repository as a zip and manually install. |
|
@pantherale0 no problem, I hope that we can add this smart curtains to HA by your integration with this data, let me know if you need more information |
|
I might just change the fork so that its specific for covers. Unfortunately I don't know what fork is actually actively maintained, head (this one) hasn't had any updates since last year, and some of the forks mentioned in #127 don't seem to be active either. Plus the codebase seems quite complex (at least in my mind). I think a better way would be to store all the datapoints, product ids and configs in a single separate location rather than embedded inside each HA platform. |
do you mean create a new integration based only in curtains and let this one for fingerbots? |
|
Yep, exactly that. Tuya devices have far too many product ids, datapoints etc and there is no easy central source to get them from. |
|
hi, after downloading and add to home assistant, I can't get the device to be paired with home assistant... always shows no unconfigured device found, and does not seems to find the curtains and the fingerbot that I usually used before, |
|
I get this entity only, with your fork:
|
|
Hi, I got the problem, is an typo on the device ID, fixing on my instance and checking if it works |
|
updated the fork now with the right IDs :) |
|
good, tried and get the device, but can't control it: debug error:
|
|
does it report the state ok? Probably a case that the datapoints needed to control are different (or accept different messages) |
|
now, after re-add the device Ican control, but I would like to know what is this attribute:
|
|
Should be motor speed, the entity name hasn't been set though. |
|
changing the number doesn't affect in anything, for now the important is working, thanks for the development!! |
|
I figured out a weird behavior now with the curtains, everytime that I restart HA or the integration, it closes the curtain, get the log:
|
|
I got the properties of the device inside tuya dev account, can you modify the code to working? { |
|
@hiagocosta I will give it a go for you, give me a couple of hours |
|
Hi @hiagocosta - could you update the integration and enable debug logs again please? I'm not 100% sure why it would be closing when the integration is setup as those DPs are the same as the blind motor, but I've improved the logging of the datapoints we do receive. Plus it now maps to a curtain motor rather than a blind motor. I have attempted to try and create an integration for covers only, but it seems that this integration has had so many changes and contributors over time it will take me a while to figure out what is going on. |
|
yeah, sure, I'm on vacation right now, but when I come back I'll do it |
|
@pantherale0 Thank you for the adjustments for the cover! I have the same motor as @hiagocosta and did play a bit with it around. Basically the integration seems to work half way right now:
Please tell me if I can help in any way debugging it. |
|
@cbrand thanks for testing what is working and what isn't, can you enable debug logging on the integration please and perform some tests? I'll need the logs to see what the datapoints are returning. Ideally need some tests done from within HA (use cover.open and cover.close services), and also same tests performed from the device itself. |
|
@pantherale0 Here you go:
|
|
1 more thing: The curtain controller also reports "learning" state. Don't know if it is relevant but for compelteness sake here is a screenshot of the devices state in my HA installation |
|
Thank you. Can you do the same but perhaps stop the cover once its half open please? I think DP ID 2 contains the current position (reversed, so 100=closed, 0=open), DP ID 1 is the control, my understanding leads me to believe this is the enum mapping for that datapoint: Open and close might be the other way round though. DP ID 3 should be the current status according to the definition provided by @hiagocosta as I can't see it reported in the debug logs |
|
Yeah it seems to me that I do not get any reports on the DP ID3 according to the logs. The "Stop" command works however as I could stop it directly in the middle. Now "open" and "close" are greyed out in the home assistant UI. Also cover: open and cover: close seem to do nothing when executing it in Home Assistant (outside of logging that data has been sent and received). I also restarted home assistant once to get the complete message log through: |
|
Hm okay with your hint I could get a bit further and testing that stop works. and here: https://github.com/pantherale0/ha_tuya_ble/blob/main/custom_components/tuya_ble/cover.py#L192 I adjusted the code base very hacky and now I can relyably trigger open and close and also do get DP updates for id 3. async def async_open_cover(self, **kwargs) -> None:
"""Open a cover."""
await self.async_set_cover_position(position=100)
datapoint = self._device.datapoints.get_or_create(
self._mapping.cover_state_dp_id,
TuyaBLEDataPointType.DT_VALUE,
0,
)
if datapoint:
self._hass.create_task(datapoint.set_value(0))
# sometimes the device does not update DP 1 so force the current state
if self._attr_current_cover_position != 100:
self._attr_is_opening = True
self.async_write_ha_state()
async def async_stop_cover(self, **kwargs: logging.Any) -> None:
"""Stop a cover."""
if self._mapping.cover_state_dp_id != 0:
datapoint = self._device.datapoints.get_or_create(
self._mapping.cover_state_dp_id,
TuyaBLEDataPointType.DT_VALUE,
1,
)
if datapoint:
self._hass.create_task(datapoint.set_value(1))
async def async_close_cover(self, **kwargs) -> None:
"""Set new target temperature."""
await self.async_set_cover_position(position=0)
datapoint = self._device.datapoints.get_or_create(
self._mapping.cover_state_dp_id,
TuyaBLEDataPointType.DT_VALUE,
2,
)
if datapoint:
self._hass.create_task(datapoint.set_value(2))
# sometimes the device does not update DP 1 so force the current state
if self._attr_current_cover_position != 0:
self._attr_is_closing = True
self.async_write_ha_state()But I can say that you are right that DP1 is set as you described:
The question for me is if the other curtain controllers also can "just" take the state set on dp1 which would allow using only the cover_state_dp_id to trigger the updates. |
|
Hmmm very interesting, whereas my blind controller doesn't seem to do anything when I update DP 1 lol... Tuya devices certainly have their quirks lol. I will "hack" around with my blind controller a bit more and see what happens. |
|
The plot thickens.. It works till the library throws an invalid data length error and then I presume no new notifications are being consumed at all till I restart home assistant completely. If I add a generic exception handler in the main ble library and just issue a log error it works continuously. I fork your version and do the adjustments I did / open a PR. I can confirm that the changes work on the cover manager. The exception handler seems to then allow to bypass (transmission?) errors. |
|
With the error handler in place the robot also works with set_cover_pos. It seems to be some transfer issue. However, the status update still does not quite work as the state update does keep the state on "opening" or "closing" and not on "open" or "closed". The error handler which I would recommend to add anyhow is here: pantherale0#1 |
|
Ok merged in, I'm going to test againt my blinds as they didn't respond when using DP 1 so may have to change the config a bit to account for that. I'll pick these changes into my preview branch too. |
|
I did today had a bit more time to debug the behavior of the robot and could trigger the issue of the robot not doing anything after sending a command. This change is in: pantherale0#5 Also I did some refactorings on the code base and fixed a state reporting issue which can be found here: It seems after playing half an hour around with opening / closing the cover and setting the position to a specific percentage degree that I cannot reproduce this "deadlock" anymore with the changes in the two PRs. |
|
Gotten round to testing this out finally.. Unfortunately it does not work on my controller (AM-43-0.45/40-ES-EB). Set position works, so will have to make some more adjustments to work with both... Damn I hate Tuya devices hahaha |
|
Finally got round to looking at this again - suddenly it started working while I was testing.. But the connection isn't overly stable.. It will do for me though because I don't plan to buy another Tuya BLE device again - this experience has been awful.
|
|
@pantherale0 Yeah that really requires a lot of unintuitive debugging from the device side which does not really make it easy to integrate. The amount of "hacks" added to get my motor running with refetching data etc. does not give me the biggest comfort on it either. Anyway thank you so much for providing the code base for the covers even though the experience is not that great. Without your work I guess I would not have window curtains which can be integrated into home assistant now. So I really appreciate the work! |
|
No problem, it all started when I thought I brought a zigbee blind controller lol. I understand why forks come and go with this integration though - a lot of code and exactly like you say, very difficult to debug / get working cleanly. I've tried to update my fork with some of the PRs from different forks in case there are folks who need features from one and the other. |
|
hi guys, I came back. |
There are literally about a hundred of different brands for this exact same motor: https://www.ebay.co.uk/itm/315278086403
They work via BLE and it would be amazing to get it working directly in HA without using a hub.
Could you please add? Let me know what details you need and I'll be happy to help by providing. Thank you.
The text was updated successfully, but these errors were encountered: