Receiving UART commands #1518
Replies: 20 comments
-
|
If your model is this aqara motor then I suggest you look at AQARA-ZNCLDJ11LM <https://github.com/HomeACcessoryKid/AQARA-ZNCLDJ11LM>
|
Beta Was this translation helpful? Give feedback.
-
|
It’s not the same motor but it does have the same rj45 connector function. Can i use the rf remote with your solution and the status will be updated in the home app? |
Beta Was this translation helpful? Give feedback.
-
|
All depends on what the protocol is. The connector is RJ11, not RJ45 BTW
|
Beta Was this translation helpful? Give feedback.
-
|
Would be awesome to have this feature, as an example I have a Tuya based fan controller that will receive RF commands from a remote to the TuyaMCU When the rf remote switches the fan on/off, alters the speed or switches the light on/off it would be really great to update the status in Homekit |
Beta Was this translation helpful? Give feedback.
-
|
Anything is happening in this topic, I have here sonoff RFR3 controlled by HAA and little people control it by RF. So would be great if this is implemented |
Beta Was this translation helpful? Give feedback.
-
|
label "wontfix" = 😞 |
Beta Was this translation helpful? Give feedback.
-
|
Yes but it is understandable. Perhaps someone with more coding knowledge than me can create a PR or a fork... I am actually starting to learn C but I'm afraid it will take a while for me to be proficient enough... |
Beta Was this translation helpful? Give feedback.
-
|
@RavenSystem would you merge in stable pull requests from forks if someone was to take this on? |
Beta Was this translation helpful? Give feedback.
-
Yes, but must be a good work, not only supporting specified devices. And it must be RAM memory friendly; this is the hardest part. |
Beta Was this translation helpful? Give feedback.
-
|
Tasmota support receiving UART commands. Maybe you can copy somthing from the code. |
Beta Was this translation helpful? Give feedback.
-
|
AFAIK Tasmota is not written in C. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like Tasmota's TuyaMCU driver is written in C |
Beta Was this translation helpful? Give feedback.
-
|
Hey all! I’m looking at trying to implement this, and want a place to write my thoughts, and hopefully sanity check it. So I see a few different ways of doing this. We could implement a raw/generic UART message definition to watch in the config (the way the UART message sending works), or, implement the actually Tuya MCU and map dpid, and fnid the way that Tasmota does it. Either way, I think you’d want to use Tasmota to enumerate which dpids map to which functions, then flash HAA. I’m leaning toward the Tuya protocol, but have very little embedded systems programming experience. So, I think I need to implement an interrupt handler that parses the messages that come back from the MCU, and then notify HomeKit, right? For my particular case (#1259) I only care about the heartbeat, when the power goes off (dpid 1 value 1 or 0), and dimmer (dpid 2, value 10-1000). So the config would map dpid to a function id. Does all of that make sense? Thoughts anyone? |
Beta Was this translation helpful? Give feedback.
-
|
I was looking to try implementing this as well once work calms down in a few weeks, but I’m happy to see someone else is interested in implementing this! I personally think that implementing the Tuya protocol is the best way to accomplish support of the tuya devices. While I’m sure generic uart messages could be configured for tuya devices, it would likely be quite error prone for users to setup. |
Beta Was this translation helpful? Give feedback.
-
|
So the tuya protocol isn’t too hard to implement. The guys at Tasmota put together a great little driver for it. I simplified it in my project here: https://github.com/paullj1/TreatLife-DS02S-HomeKit/tree/main That said, it seems the owner of this repo is unwilling to integrate the support. I think the most ideal way forward would be to fork this repo, strip it down to the most minimal functionality, and then implement only a JSON configurable Tuya device. Otherwise, you’ll be battling @RavenSystem for size in the flash memory. |
Beta Was this translation helpful? Give feedback.
-
|
@paullj1 Would you be willing to work out the solution you mention? My coding skills are none existent but I do have some curtains that would benefit greatly from this. |
Beta Was this translation helpful? Give feedback.
-
|
@tonysprenk I don’t have a particular use for it anymore. It would be far easier to adapt the project I made for your curtains. The main advantage of HAA is for more complex configurations, but in the case if the Tuya MCU, most of the inputs are handled directly by the MCU, so you can’t override them easily to extend their functionality. In other words, I’m not sure what you gain by making HAA handle Tuya, versus just modifying the base code I have linked in my project for your application. |
Beta Was this translation helpful? Give feedback.
-
|
About HAA and this feature, I am not interested to waste flash including Tuya and other UART brands. It must be generic and declared in JSON, like IR commands, network action... I could include IR codes for Samsung, Panasonic, Daikin... wasting a lot of flash storage, and limiting HAA use to those brands. Same happens here with Tuya UART commands. Some people want Tuya because you have Tuya, but others with Shelly will want Shelly UART... For example, I have not any Tuya device, but I have some Shelly devices that use Shelly UART protocol. But it is not important, because currently, HAA has 8000 bytes free only, and there is not possible to store any protocol hardcoded into firmware. 8000 bytes is a big challenge, and I will use it for historical registers code. |
Beta Was this translation helpful? Give feedback.
-
|
@paullj1 Reason why everyone is so obsessed with HAA is its incredible stability and improvements over time. Taking into account the flash storage constraints, it looks any special new features outside @RavenSystem radar have no luck. However, before someone would try to strip down HAA, it would make sense to ask @RavenSystem if he would be willing/interested/have time to support such approach? In this way, any improvements or security fixes on HAA's baseline code by @RavenSystem would easily be adopted to any other firmware which was based on HAA's striped down code. I hope this make sense. |
Beta Was this translation helpful? Give feedback.
-
|
Any interest in a larger image for devices with 2mb flash (ESP8266 EX)? |
Beta Was this translation helpful? Give feedback.
-
Now that sending UART commands is supported by HAA it would be really nice to be able to receive and process UART commands from the secondary MCU. This is especially helpful when a device has more than one way of controlling it. For example my curtains can now be controlled with the home app but they also have a feature where if you pull the curtain slightly to open or close the motor will take over automatically. When that happens the MCU sends a packet to tell the ESP that the curtain is opening or closing. But because HAA doesn’t support receiving UART communications, only sending, the status of the curtain stays the same in the home app even though the physical state has changed. This can also be useful for obstruction detection.
Tasmota handles this in their tuymcu templates so it should be possible.
If anybody has any more info or ideas on this feel free to comment.
More info here.
Beta Was this translation helpful? Give feedback.
All reactions