I am using sonoff pow R3 (tasmotized) to read the all energy attributes using ohlalab driver. it works fine for basic functions like on/off and displaying values on the dashboard.
The issue have have is using these attributes in rule machine. they are all text. For example I cannot do a rule when the current value is less than 2 Amp for example.
I also noticed that in the rule machine itself, it does not show all the attributes in the device when trying to use a local or a global variables.
The best solution would really be to fix the driver to report only the numeric component as the value of the standard attributes because that is how they are specified. It would probably also be a good idea to do the same for the custom attributes that are similar in nature, just because it makes this kind of thing easier (and it's consistent with other attributes where the unit is part of the event but not the attribute value), but at least with those, there aren't any hard and fast rules.
But because I assume you aren't interested in modifying this driver and the driver author has moved on, that leaves you two options. Either find a different driver that works (I'm not familiar with this device so don't know of any; there may be some), or use Rule Machine variable operations to get what you want.
To do the latter thing, which it seems is also more or less what you're asking: first, you'll need a variable (local or hub are both fine) to store the value of the desired attribute in. This should be a string variable (to match the attribute value type). You'll also need a number or decimal variable to store the actual value you're interested in--eventually. You will also need a third string variable to hold a string you split apart from the first variable (see below). Then, you can use various Rule Machine variable operators to extract the data you need from the first variable and, eventually, get it into the second. One such operation lets you split a variable based on some delimiting character, which in your case seems like it could be the space character--if there's always a space between the "real" value and the units. (In the "Set Variable" action, use "token" as the operation, a single space character as the delimiter, and use index...0, I think, unless they start at 1?) Then you can use another Rule Machine variable operation to convert the "numeric string" into an actual number variable.
But yeah, this would be a lot easier with a driver that followed the conventions.
Thank you for your reply. Changing the code it mission impossible for me.
I have created three variables "miancurrentstring" as the variable to put the cuurent string from the device attribute. the second is "maincurrentvlaue" a decimal to store the value as a number and the third is "maincurrentsplit" to slpit the string from value and unit. see below
I know i am doing something wrong. please can you guide me?
I have a general question about rule machine. it works with triggers. I was wondering if the RM will only trigger once when the trigger condition is true. or does it check the conditions over and over again as long as the trigger condition is true? my understanding of trigger it does its conditions once every time the trigger condition goes from false to true.
Why I am asking this question is because i want the conditions i put in the RM to be continuously checked?
Turn off the "variable index?" option. You are using a fixed index, the first position (I forget if this is 0 or 1 in RM...) and can just specify that value without using a variable for it.
Triggers represent events, not conditions, and as such they do not have truth values. They are just a moment in time, when that event happens. (The new "sticky triggers," the "stays" option, muddles this a bit, but it's still the same basic idea.) When a trigger event happens (unless a required expression is used and is false), the Rule actions run. A conditional in Rule axtikna will not do anything on its own. It will just be evaluated at the time when it is reached in execution.
Thank you for your help. I got the conversion to work properly. But my question now is how to make the below RM runs indefinitely without any triggers. I want to keep the "maincurrentvalue" updated all the time so that i can use it in a different RM.
My apologize for lots of questions. I am a beginner with HE.
Seems like it should work if you trigger on the "real" device attribute changing (you may need to use "Custom Attribute" if Rule Machine chokes on a standard-numeric value being presented as a string).
I also ran into the string/number problem in Rule Machine:
In Rule Machine under Manage or Create Conditions I choose my Aeotek Energy Meter Gen5 using the driver by Taylor Vierrether (hubitat/Drivers at main · viertaxa/hubitat · GitHub). I set an Energy level of 0.5 to compare with and try different Comparison operators to see what happens. Some comparisons fail silently because the driver declares energy as a string and Rule Machine wants a number:
Energy level of 22 Oak Aeotec Energy Meter Gen5(18.571) is > 0.5 FALSE
Energy level of 22 Oak Aeotec Energy Meter Gen5(18.571) is >= 0.5 FALSE
I put 18.571 into the Energy level box and got this nonsense:
Energy level of 22 Oak Aeotec Energy Meter Gen5(18.571) is ≠ 18.571 TRUE
Energy level of 22 Oak Aeotec Energy Meter Gen5(18.571) is = 18.571 FALSE
Rule Machine gives no indication of what the problem is. You have to go rummaging through the log files to find:
error invalid operand type for 18.997(string) > 0.5(number)
It would be lovely if Rule Machine could be liberal in what it accepts and convert the string to a number if needed. Robustness principle - Wikipedia
If that isn't reasonable, an on-screen error message from Rule Machine to the user explaining what the problem is would be helpful, rather than generating an error message hidden in the log file.
(I edited my copy of Taylor's driver to declare the attributes as numbers instead of strings and submitted an issue report.)
The logs should be your primary go-to tool whenever things don't work the way you expect, not something you complain about having to use.
Automatically converting types is not the panacea you might think. There are reasons that things have specific types, and forced type conversions do not necessarily fix what's wrong, and may introduce additional 'hidden' errors. It is incumbent on driver authors to use the proper types for attributes, to make the driver conform to the capability definitions. Putting a string into a number attribute is simply buggy code. It doesn't make sense for RM or any other built-in app to even begin to deal with this sort of fundamental bug, to attempt to cure its flaws would be a fool's errand. But, again, the logs are your friend. Because of them you knew what was wrong with that driver, and it was not difficult to fix it. Makes you wonder how it happened in the first place: numbers are numbers, after all.
Similar comment to the above. Chasing down every possible failure of a driver is not something that should be put on RM, or any other app. Rather, the apps should be able to rely on the drivers to conform to their capability definitions. While it is possible to put 'a diaper' on code that catches errors of this sort, to allow UI presentation of the error, this would represent a rather large burden to place on all of the apps -- a lot of code just to cope with driver authors who are careless and push buggy code on other users.
I just received my Aeotec HEM Gen5 as well and am running into the same problem. Can you give me a clue how to change the string types into number? I'm not a programmer.
The thing is useless if you can't do anything with the data.
Edit: I managed to look in the driver and change the power type from string to number. It worked! It's too bad it looks like the driver has effectively been abandoned. The unit seems like a good one.
Edit2; I've got it turning on and off a light if total house power goes over or under 525 watts. Cool.
