Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New HAss Discovery (3/4): INPUTS #7901

Merged
merged 1 commit into from
Mar 12, 2020
Merged

New HAss Discovery (3/4): INPUTS #7901

merged 1 commit into from
Mar 12, 2020

Conversation

effelle
Copy link
Contributor

@effelle effelle commented Mar 12, 2020

Description:

Add support for triggers under Home Assistant for automation control. Available starting from version 0.106.6.

Tasmota is the first firmware using those new triggers.

More information about Triggers here and there.

What's new: 

1. Buttons:

  • To have them available under Home Assistant ButtonTopic must be set to 1 or a custom name;
  • SetOption1, SetOption11 and SetOption13 are now supported;
  •  When used with ButtonTopic 1, a Button can only generate a HOLD trigger.

 2. Switches:

  • To have them available under Home Assistant SwitchTopic must be set to a custom name;
  • All SwitchMode type are available but 11 and 12 will generate just a TOGGLE trigger;
  • switches with a known state (ON/OFF) will be created as Binary_Sensor;
  • Switches with unknown state (TOGGLE) will be created as Trigger;
  • HOLD and double click are now supported;
  • Some SwitchMode can have a binary_sensor and a trigger at the same time (ex Switchmode 5).

Also:
3. New environmental sensors added: SGP30, CCS811 and SCD30.
4. Updated some units of measure.
5. Code optimization.

A special note: Thanks to @emontnemery for help in understanding how to add the new triggers and also to @arendst for the quick implementation of new functions necessary to optimize the code. 

Related issue (if applicable): fixes #7599 , #7837 and #7848

Checklist:

  • The pull request is done against the latest dev branch
  • Only relevant files were touched
  • Only one feature/fix was added per PR.
  • The code change is tested and works on core 2.6.1
  • The code change pass travis tests. Your PR cannot be merged unless tests pass
  • I accept the CLA.

@arendst arendst merged commit 59d3103 into arendst:development Mar 12, 2020
arendst added a commit that referenced this pull request Mar 13, 2020
- Bump version to 8.1.0.11
- Add HAss Discovery support for Button and Switch triggers by Federico Leoni (#7901)
@septillion-git
Copy link

@effelle What's the reason to force a switchtopic to have them discovered in HA? That topic isn't used. Because this change (from 8.1.0, which was not on the change list) made me search for quite some time... 😢

@effelle
Copy link
Contributor Author

effelle commented Jun 16, 2020

@septillion-git if you look on switchtopic on our buttons and switches documentation you will find that:

SwitchTopic <value> sends an MQTT message command to the custom topic. This does not change the state of the devices power.

meaning the switches will be independent. Is not a new feature in Tasmota, on the contrary was and still is the official way to decouple switches from power devices (relays) from a long time, so definitely nothing new. Having the switches/buttons created in Home Assistant without decoupling them was a bug, a not intended feature, and the change was decided in conjunction with HA devs as a preliminary support for the new mqtt triggers now completely implemented.
Until I'll change the switches (no ETA, sorry) into something like i did for the buttons, now controlled with SetOption73, they will stay that way.
If you don't want to set switchtopic to a custom name, remembering that is a setting born for this type of configuration, you only solution is to manually create the entities under Home Assistant.
More information about how the new Discovery works can be found on our Home Assistant documentation.

About the change list, perhaps you looked in the wrong version?
Since this PR was merged on dev version 8.1.0.11 it was correctly reported on the changelog for version 8.2.0 Elliot. You will not find this PR on 8.3.0 changelog for obvious reasons.

If you need more assistance please address your requests to our Tasmota Support Discord Chat, thanks!

@septillion-git
Copy link

septillion-git commented Jun 16, 2020

@effelle thank you very much for this lengthy explanation! And when reading the next piece, don't get me wrong! I really appreciate all the hard work. But this is just my view as a user.

I didn't know it used to be a "bug". I run Tasmota on them since 7.something and I'm sure the documentation was in line back then. Aka, all the time the switches where visible in HA. And I simply decoupled them by making a rule for them as was explained in the documentation. And I toggled that rule based on MQTT#(dis)connect in order to regain local action as fall back.

So for me as a user is all looked like it was meant to be. For me as a user documentation and function where in line with switches discovered. #7901 was indeed mentioned in the change list of 8.2.0 but I would have never ever guessed (without reading the whole PR) that it would change the discovery of switches in HA. Aka, for me it came as a huge breaking change.

And you say " remembering that is a setting born for this type of configuration". But I don't get why. You now make a new topic to post the state to but that topic isn't used by HA discovery (luckily!) yet that is the toggle to make switches discoverable. To me, switchtopic sounds like a way to directly control another Tasmota(/device) over MQTT and I don't see a link to HA. (Although losing rules when a switchtopic is set is weird from a user perspective.)

And I say luckily because the way I now fixed it is to set the same switchtopic on all Tasmota's and just let it publish there without anyone ever reading that topic. Bit "wasteful" but at least all Tasmota's can use the same topic. And I use MQTT#(dis)connect to set or reset that switchtopic in order to get local control as fall back support.

And yeah, I would like to help more with the code itself but the whole project is pretty daunting! Getting an overview of where to find what and how things are dealt with (storing of settings, hooks etc) is kind of impossible. At least for a hobbyist like me. A page with general info like that would be great. But again, not a negative comment. I know it's one of the least exiting things to make and can be pretty hard and time-consuming. So from time to time I might take a new dive into the code.

@effelle
Copy link
Contributor Author

effelle commented Jun 16, 2020

No problem Timo, I like to have feedbacks.
I know in the old version switches/buttons were automatically created, in fact I'm the one who enabled (and wrote the docs for) them before starting to work on triggers and new inputs to solve an issue and then they stayed that way for a long time due to the lack of time from my side.

I understand your point of view about the Discovery and as I said the good news is I want to change switches to something similar of what I've done with buttons, mostly to re-add the ability to use rules in conjunction. The bad news is there is no ETA, because it involves a change on base code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MQTT Discovery: Switches & Multi-Press/Toggle
3 participants