feat(tasmota.py): add tasmota as a controller #575
Conversation
|
Example usage: |
|
Hi @cmiguelcabral, What does the Tasmota integration bring to the table that MQTT is not already supporting? In general, I only accept new integration (note integration is different than devices) when it brings something new that is not part of DYI solutions. For this, I recommend to configure it through YAML with no need of changing code. For example, you could achieve the same with the following config: luz_do_escritorio:
module: controllerx
class: LightController
integration:
name: mqtt
payload_key: Switch1
controller: stat/botoneira_do_escritorio/RESULT
light: light.luz_do_escritorio
mapping:
"SINGLE": "toggle"
"DOUBLE": "on_min_brightness"
"TRIPLE": "set_half_brightness"
"QUAD": "on_full_brightness"
"HOLD": "on_min_max_brightness"
luz_da_secretaria:
module: controllerx
class: LightController
integration:
name: mqtt
payload_key: Button2
controller: stat/botoneira_do_escritorio/RESULT
light: light.luz_do_escritorio
mapping:
"TOGGLE": "toggle"
"ON": "on"
"OFF": "off"_min_brightness
"HOLD": "on_min_max_brightness"Are these controllers/devices always sending same actions that you configured, or they are customized to your setup? Regards, |
|
The example you posted doesn't work because Tasmota sends the message in a nested property. If you check your documentation (https://xaviml.github.io/controllerx/examples/tasmota-switchmode11/), you see that you are using rules inside Tasmota to make it work with ControllerX. I don't see why this feature couldn't be part of ControllerX as it doesn't influence anything about other integrations/controllers and Tasmota is being used more and more by the community. I was also thinking about adding the opposite later, making ControllerX control Tasmota directly over MQTT without going over HA. (Something like the Z2MLight). |
|
Hi @cmiguelcabral , So, Tasmota allows to integrate devices in a "standard" way? I though it was only for DYI purposes where one can build their own actions. If so, I have these questions to consider it as a new integration or not:
Sorry for all these questions, but I've never used Tasmota and I need to unserstand how to make it fit with ControllerX. Thanks! |
|
Hi @xaviml (long time, no see 😉) and @cmiguelcabral Just a few comments from the guy who initiated that these changes actually was done to Tasmota switchmode11 and did that ControllerX documentation as well 🙂 It was NOT meant as a 'standard' part of ControllerX though, as the Tasmota config for the average user might be a bit overwhelming. So if an actual Tasmota configuration in ControllerX could make the nested messages somewhat more user friendly and all communication is done via MQTT, then I guess it would be an improvement for all using Tasmota and ControllerX together. Regards |
|
I would be happy to answer all the questions you have. You can set peripherals (Digital Inputs) as Switches or Buttons. All of them will always publish the message in the same type of payload, and that would be:
But the payload will always be the same, independently of the type of peripheral you use. This is why I thought it would make sense to add it to ControlleX as this opens a huge amount of possibilities. Right now, at my place, I have some dozens of Zigbee bulbs, all connected through a device running Tasmota in the wall. I use Tasmota to send commands to the bulbs, and in the case MQTT is down, it would then control its relay directly. ControllerX makes it way easier to do instead of using automations in HA or using the rules on Tasmota. Please consider this before discarding it... |
Cheers Henning!! I think that a guy that has HACS, Appdaemon and ControllerX installed, can easilly use Tasmota. Regards, |
|
Well, I was mostly thinking of the needed Tasmota rule configuration that could be somewhat tricky to understand. Anyway, seems like we share somewhat of identical setup with 'Tasmotized' devices in behind the wall switches and Zigbee lights everywhere 😉 The main reason I took this route some years ago was the WAF 👩🦰 and the fallback to the Tasmota switch relays in the event that HA/MQTT server was down for whatever reason. Cant you just use CLEAR as HOLD_RELEASE ? I haven't really looked at those Tasmota logs for some years. But AFAIR it only fires once (and instantly) upon button release. |
|
Hi Miguel, Thanks for the explanation. First of all, sorry if I gave you the impression that I would be discarding it, I just needed a bit more of context, and you gave it to me :) Second, it totally makes sense to have a Tasmota integration given how Tasmota works, but I still have a question: I see in your PR you only added a TasmotaLightController. Whereas other integrations have multiple device that are supported. Is this because no matter the device, they will always trigger the same action events? Is the idea to use same controller class for all devices that are integrated with Tasmota? Regarding the PR:
Regards, |
Because in Tasmota you can have many buttons or switches, so it's possible for you to have Button1, Button2, Button3...(and so on) and at the same time Switch1, Switch2, Switch3 (and so on). AFAIK you can go up to 8 buttons and 8 switches together in the same device. I just made this as an example. As Buttons and switches have different actions I split them, but they actually can be joined together as a unique type with the actions: And as I told you before in the email, this is just a draft for you to see and tell me what you want me to do or change before opening the actual PR. |
|
Hi @cmiguelcabral , So these Button1, Button2, ... names are automatically set by tasmota or is set by you? Also, could you send a link or explain what actions are performed to trigger those events?
Thanks! I do appreciate your PR and it is something it makes sense to have in ControllerX, so we can work together to integrate. The question is: do you want to work on the changes, or you want me (or I can) work in your branch? Regards, |
Tasmota sets those names automatically, but you can change those names to others that you want. That's why I made it possible to choose the name using the "device" property. If you change the name for, let's say "best_switch_ever", then you get:
Here you can find documentation about the way buttons and switches work:
We can do it either way. This is how you set them on Tasmota: |
|
By the way, |
|
Looking into it now, we will either need to merge the buttons and the switches into only "get_default_actions_mapping", or add a separate property to define if it's a button or a switch. So we can do it in two ways: 2: Here's an example of it working; |
You're absolutely right, @cmiguelcabral. I'm currently running old, old Tasmota v9.2.0.1 on my production switches (if it ain't broke - don't fix it) and neither HOLD nor CLEAR is there as standard button action. But again, I haven't configured any buttons at all, as I'm solely relying on the switch states and my rules. In one of my other devices I can see that the HOLD action is there, but not the CLEAR (HOLD_RELEASE). |
That's it!! So we can add the CLEAR to the list of Button actions. |
Will |
No, only one is fired. |
|
That's actually the problem with SwitchMode 11/12. As the TOGGLE is sent always even together with DOUBLE, or HOLD. And the POWER_RELEASE is also fired everytime. |
|
Well, it's actually by design that the internal Tasmota switchstates are fired that way. Above issue has in many cases been debated with one button devices. There are use cases where you want the initial first TOGGLE fired instantly without any lag at all and are willing to sacrifice the ease of implementation. Other use cases that are not extremely time important, would on the other hand benefit from the much easier event handling with only one event fired. |
|
This is also the reason why I've restricted my Tasmota events to either:
|
|
Yes, I understand and agree with you. |
I agree. That seems to be a bug indeed. Has always thought that the general Tasmota events were somewhat messy. A Tasmota event 'clean up' seems to be needed 😉 |
True, but with SetOption73 and/or SetOption114 enabled, if you don't use Switchmode 11/12, it works decently and makes up a nice controller. |
|
Hi @cmiguelcabral ,
Sounds good to me. I will be leaving some comments in the PR.
Let's go with 2nd option, although I am not convinced about the naming since we will have a
That is great!!
I suggest removing those from the PR for now if they still have some bugs. They can be added once they serve a purpose and no bugs are presented. Regards, |
There was a problem hiding this comment.
PR looks good! But some changes will be required apart from the ones already mentioned:
- Add documentation about new integration in
docs/docs/start/integrations.md. Probably mention that this integration requires enabling MQTT plugin for AppDaemon. You can reference this page, like done for MQTT and Zigbee2MQTT integrations. - Add
get_tasmota_actions_mapping()function inapps/controllerx/cx_core/controller.py, like done with other integrations. - It is better if you use this image for the devices. You will need to copy and paste the same iamge and change the name according to their device names (which is the
classnames without theLightControllerorSwitchControllerpart). - Add an entry to
RELEASE_NOTES.md. Uncomment the## :pencil2: Featurestitle and add an entry explaining the new integration with 1 short sentence.
Thanks!
|
|
||
| class TasmotaIntegration(Integration): | ||
| name = "tasmota" | ||
|
|
There was a problem hiding this comment.
Since device attribute is mandatory, I suggest overwriting the __init__() to check if kwargs contains device.
There was a problem hiding this comment.
Regarding this, I will need some help, as this is the first time I code python... :-\
|
By the way, I recommend you pulling the latest from |
Using SO73 (buttons) or SO114 (switches), is possible to use Tasmota as a controller. This commits adds compatibility to ControllerX to use it.
cmiguelcabral
force-pushed
the
tasmota
branch
from
8a386f3
to
2b6b3e8
Compare
|
Hi @cmiguelcabral , Fantastic job!!
The default action you chose looks good to me. In the end, it will vary depending on the user, so they can configure that with custom mappings.
That is great!! MQTT integration with ControllerX surprised me the first time I added it.. There is a lot of difference wrt listening to HA entities...
If you want and allow me, I will be adding an extra commit on top of yours to:
Thank you :) |
I'm thinking about some examples of how to use this. But that can come later.
Please do it. |
|
@cmiguelcabral go ahead and check my last commit as well as testing the following if possible:
Thanks! |
Codecov ReportBase: 96% // Head: 96% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #575 +/- ##
===================================
Coverage 96% 96%
===================================
Files 61 63 +2
Lines 2530 2590 +60
===================================
+ Hits 2427 2486 +59
- Misses 103 104 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
Wow - you guys are... fast!🚀🚀😆 And Xavi, I already told you many months ago that HA state machine is..... ☠slow (compared to MQTT)🤣 |
You did @htvekov ... and I am glad you pushed me to integrate MQTT into ControllerX, it is one of the top features in my opinion! Once @cmiguelcabral is happy with the checks, I will merge and create a prerelease, so you can download easily from HACS and test it out. Regards, |
|
Go ahead!! @htvekov, in fact, it is way better when using mqtt directly. |
Will it be now that you update your Tasmotas?! |
|
Wait... Something is not right:
It works, but I get this error every time I push a button.
Everything seems ok to me. |
|
I get what's going on now! This is an example of a device with 4 components. When I press one, the other 3 will throw errors:
|
| if component_key in payload: | ||
| try: | ||
| action_key = str(json.loads(payload)[component_key][payload_key]) | ||
| except json.decoder.JSONDecodeError: | ||
| raise ValueError( | ||
| f"`key` is being used ({payload_key}). " | ||
| f"Following payload is not a valid JSON: {payload}" | ||
| ) | ||
| except KeyError: | ||
| raise ValueError( | ||
| f"Following payload does not contain `{payload_key}`: {payload}" | ||
| ) | ||
| await self.controller.handle_action(action_key) |
There was a problem hiding this comment.
I think this will need to be reverted.
|
Hi @cmiguelcabral , I understand, I assumed that component_key was always mandatory. I will revert to previous behaviour and change tests accordingly. What it matters is that if "component" is not in the payload, it should ignore the message and not error out. Thanks! |
|
Yes, that's it. In this case, all the changes you made are ok, just this part needs to be adapted to ignore when the command comes from other component. if component_key not in payload:
return |
|
Hi @cmiguelcabral, I added the fix to not error out if the key that fails with is the component_key. Could you please check again that everything is okay. Then, I will merge the PR. Thanks! |
I noticed and just checked out your commit. |
|
Now everything seems to be working perfectly.
|
|
I think now it's done! Anyway, I'm no python expert, but I would do it the way I suggested, I think it has better performance. try:
action_key = str(json.loads(payload)[component_key][payload_key])
except json.decoder.JSONDecodeError:
raise ValueError(
f"`key` is being used ({payload_key}). "
f"Following payload is not a valid JSON: {payload}"
)
except KeyError as e:
if e.args[0] == component_key:
returnIf you just discard it at the beginning, you'll avoid all of this... if component_key not in payload:
return |
|
You convinced me.. I didn't want to do it at first because "payload" is a string, and the "component_key not in payload" conditions just checks that the string "component_key" is preset in the string "payload". However, I agree that the solution just works fine and as you said it would be better for performance. Just force pushed last commit. Thank you for raising the concern :) |
|
You can no check new documentation here:
I am launching now new beta release. In a few minutes, it will be out to grab from HACS: https://github.com/xaviml/controllerx/releases/tag/v4.24.0b0 |
|
Yey!!! I don't know how many people will actually use this, but for me will be a lifesaver!! I have so many devices that I need to configure one by one, and now, everything will be done in just one place, on yaml files!! Thank you for the patience!! |
|
I will let you know if I need your help if someone comes with an issue with the tasmota integration. Thank you for the work and the contribution! :) |
Be my guest, I'll be happy to help!
I really enjoyed doing this. |
Using SO73 (buttons) or SO114 (switches), is possible to use Tasmota as a controller. This commits adds compatibility to ControllerX to use it.