Hello,
I have a number of Homematic three-state HM-Sec-RHS window handle devices, which in HA are identified as sensors. Each sensor reports text info as closed/open/tilted, which is working fine.
The Homematic devices used to be controlled by a separate FHEM system that sent individual status info for each window into my LCN bus system. Three LEDs on the switch panel were then used to display per floor info: off for everything closed, blinking for an open window and on for a tilted one.
I have now migrated all Homematic devices from FHEM to HA/Raspberrymatic. I plan to eventually put some tablets on the walls. Until then I would like to reestablish the window status display using the LEDs
One possibility would be to copy the old functionality by adding an automation for each individual window. However, I thought of using the Group functionality of HA instead to avoid having to set up that many automations, but run into difficulties: the RHS device is a sensor that reports its status as a non-numeric information. Grouping them leads to the group status being always āunavailableā. Is there a chance to have the group use the text info instead?
So no other efficient way than having to look at the 17 windows (like in your example for 1-3) separately for each floor.
The reality is even more complicated because I also have some intelligent windows handles that report off/on/unknown. Hence the need to combine two sensor sets for each of the three states.
And all this for one little LED
In FHEM I was calling a special URL that directly set the window status in LCN. Maybe running a separate RESTful command for each window is easier and more flexible.
That looks good! I had already wondered what labels are for. If I understand this correctly, the code line returns the number of entities that are either open or on.
Iāll check it out over the weekend and report back.
So the automation needs to run upon any state change, which I believe it does.
After reading through the trigger documentation page I am a bit lost. Could you kindly guide me a little bit?
Does the trigger value definition work it if I donāt use list | count in the trigger value_template?
ShouId I use Conditions: and evaluate three different template checks (if open >0 then LED blink, elseif tilted >0 then LED on, else LED off) or is there a better way?.
Each trigger will cause the automation to fire when any one changes from false to true; see the first paragraph of the template trigger docs.
Try it in the template editor (developer tools ā template). The output of the select filter will be a Python generator object, so if you omit | list | count but leave > 0 youāll get an error because you canāt conpare a generator object to an integer.
The way Tom suggested originally made sense to me, using 3 binary template sensors. However if you donāt want to create any entities and instead want to do it all in an automation, I think youāll need 6 template triggers and then I would use a choose block in the actions, which is essentially a more flexible version of the if/then/else statement.
You will need 6 template triggers because youāll need 3 for when each one goes > 0 and youāll need 3 more for when each one goes < 1 (or == 0). Then in your choose block youāll have 3 options, each with the appropriate template conditions.
Checking the template expressions in the developer tools section give the desired result. The template conditions in my vaml should be ok, but I donāt know how to set the trigger definition that it fires upon any change.Right now it does nothing.
You will need more triggers. You will need a template trigger for each condition that can cause a LED to change behavior:
1 or more windows open
zero windows open
1 or more windows tilted/unknown
zero windows tilted/unknown
1 or more windows closed
0 windows closed
I crossed out the last two because they are redundant with the first 4. For example you donāt need to trigger when you get to zero windows closed because that necessarily means a trigger would occur for either 1 or more windows open or 1 or more windows tilted/unknown. So I originally said you need 6 triggers, but actually 4 will suffice. Itās worth mentioning that including the extra triggers would just make the automation run twice if itās in queued or parallel mode, or once if itās in single or restart mode. Either way, the extra triggers wouldnāt hurt anything, theyāre just unnecessary.
Template triggers get evaluated as either true or false, and only fire when they change from false to true. So it is not possible to have a template trigger count a number and then fire when the number changes. But there are many (nearly unlimited) alternatives. Here are some decent ones:
have a state trigger, and you select each of your windows to include. You wonāt be able to use the label entities though, youāll have to select each entity manually.
create a separate template sensor which has itās state as the count of windows that are open, and then set up this automation with a state trigger that will fire whenever that template sensor changes. You will probably want one template sensor calculating the number of open windows, and another template sensor calculating the number of tilted windows. And you can trigger when either one changes.
You have an extra comma:
{{ label_entities('Fenster Bad/WC')| select('is_state', ['open','on']), | list | count > 0 }}
^
here
That will of course work - and is easier to read for me. Maybe not as elegant as the concise syntax that I see here and thereā¦
Yet if I check for a list of (in total) 27 windows, or maybe 10 per floor, I may as well treat each window individually by reporting its status directly into my LCN bus system where the display logic is already implemented.
That gets close to what I was doing in my FHEM/Homematic setup. However, it was easier there by nestingn simple structure commands, i.e.
floor1 would then be used to define a notify to fire upon any window state change in floor1 (room1 to 3), running an action sequence. The underlying concept is the same and I believe one can achieve something similar in HA, but it appears more complicated at first glance.
I guess I need to study the docs a little bit more before I can fully grab HAās capabilities.
I had read the instruction and tried that but it threw another error. With added quotes I get
bad indentation of a mapping entry (72:41)
72 | ... template: '{{ label_entities('Fenster Bad/WC')| select('is_st ...
-----------------------------------------^
I begin to see that indentation is important, so is the use of hyphens and colons. The documentation is not very comprehensive in this direction. The template section has a few examples, but none with the usage of template value. What is even more confusing is that on the other hand HA is not always strict on its semantics, maybe because of legacy and downward compatibility for older code. So searching the forum for solutions is kind of confusing when looking at the code sniplets.
I am extremely grateful that you sacrify your time for me. However, mastering these advanced concepts require a more thorough understanding of yaml programming and object creation that is probably above a newbieās level.
I am not an IT Pro but just a chemist with basic programming skills. I mastered PERL for FHEM/Homematic and will certainly not give up on YAML. Nonetheless, at this moment I am a little bit frustrated because I am down to trial and error.
I can provide some more thorough help if you provide the complete YAML you are using. Itās difficult to see what mistakes you might be making, especially with indentations, if I can only see a line or two because I donāt know what comes before it.
One thing I can comment on: the template must be surrounded by quotes that donāt match any quotes that are inside the template. In other words, use double quotes outside the template if single quotes are used inside the template. Or use multiline format.
OK, I now have a code that is semantically correct. I can see with development tools that the template switches form false to true and back if I toggle the entity state between closed and open. But the condition part is not executed. I have the feeling that listing multiple entities in the trigger definition that way is not right.
I would strongly recommend you build your automations using the UI interface until you get to the point where you are confident in your YAML coding skills. Or at least build them piecewise using the UI: Create just a single trigger (or condition or action) with the UI, test it to make sure it works, then switch over to YAML mode and copy the code out of the editor and place it into the automation that you are manually coding. You can do this step-by-step and you will end up with an automation that you have much more confidence in.
Also continue to go back to look for errors in your logs. If nothing is happening when you trigger the automation, there will certainly be errors there that will guide you to the problem.
For YAML, indentation is extremely important. In your choose block, the format should be:
actions:
- choose:
- conditions:
- # conditions for the first option
sequence:
- # actions for the first option
- conditions:
- # conditions for the second option
sequence:
- # actions for the second option
...
You had extra indentation in front of the sequence: lines. You were also missing the hyphen in front of the 3rd condition which makes it a dictionary (or āmappingā) instead of a list.
Iām also not certain that comments are allowed on the same line as valid YAML, but I left them in the code below but I didnāt verify it worked.
You can also refer to this page for automation YAML information and examples.
Hereās what I think you should have for your code: