rpn: rfbridge rules #2302
rpn: rfbridge rules #2302
Conversation
|
Regarding operator's syntax - it simply stops execution, so anything to the right of it is silently dropped and we jump to the next rules string. Originally, state was declared as variable - $relay0, $temperature0 etc., - but then we would need to have additional operator |
|
I have built a firmware including RPN rules using your code from: 451a413 It builds but I can't get access to the initial webUI. During build I get: I don't know if that would cause the firmware to not run correctly. Build config is: |
|
Warning points to the exact issue. Enabling rfbridge relay provider is broken atm :/ diff --git a/code/espurna/relay.cpp b/code/espurna/relay.cpp
index eca66fc5..ab6f1169 100644
--- a/code/espurna/relay.cpp
+++ b/code/espurna/relay.cpp
@@ -1473,15 +1473,13 @@ void _relaySetupAdhoc() {
for (unsigned char id = 0; id < RelaysMax; ++id) {
const auto pin = _relayPin(id);
- #if (RELAY_PROVIDER == RELAY_PROVIDER_RELAY) || (RELAY_PROVIDER == RELAY_PROVIDER_LIGHT)
- if (!gpioValid(pin)) {
- break;
- }
- #elif (RELAY_PROVIDER == RELAY_PROVIDER_MCP23S08)
+ #if (RELAY_PROVIDER == RELAY_PROVIDER_MCP23S08)
if (!mcpGpioValid(pin)) {
+ #else
+ if (!gpioValid(pin)) {
+ #endif
break;
}
- #endif
_relays.emplace_back(
std::make_unique<gpio_type>(_relayPin(id)), |
|
Re: if the intent is to use rules and not to use relays to send codes, just keep the default provider setting. dummy relay count setting will still work |
|
The intent is to either have espurna publish the received 433MHz code as an MQTT topic to allow openHAB to do something when it sees that code or, have a dummy relay toggle based on the 433MHz code. The MQTT topic for that relay would be the openHAB trigger instead. |
|
RELAY_PROVIDER_RFBRIDGE only handles the sending. Rfbridge code handles the receiving part independently and tries to toggle things when rfbON# / rfbOFF# keys match. Btw, make sure it isn't configured like that, rules will cause a conflict. See RF panel / those keys and delete them. |
|
I'll comment out the |
|
Building with: I have the following output: I'll have to get my head around RPN rules now to create a rule that either process the second code and do something via MQTT or add the dummy relays back in and switch those using RPN rules. |
? Translated as: compare latest received code with "00D7410E" and make sure it has hits=2 (see |
|
As another example, check this out in terminal. Running multiple times it should send either 0 or 1 to the "test" topic (note the escaped quotes)
Note the slightly different syntax for variables, using Or, another option use built-in stringification of the boolean value into "true" or "false" (as edit3: updated for 0.23.0 |
code/espurna/rpnrules.cpp
Outdated
|
|
||
| // hits == 1 is a single click, hits == 5 is long click | ||
| // we sort-of can distinguish single and double via timestamp, but it has a **very** unreliable timing | ||
| if ((*result).hits > hits.toUint()) { |
There was a problem hiding this comment.
This check and the one below need to be slightly reworked to only trigger themselves when 'hits' stayed the same for a specific interval. After that, we could throw out the code instead of keeping it.
Another apparent issue with the check is eq vs. gt difference, we must have the exact number of hits or rule does not work. Perhaps the operator could push 'hits' on the stack when value stabilizes, and comparison could happen in the expression (including greater-than, greater-than-or-equal, etc.)
There was a problem hiding this comment.
note-to-self:
Yep, seems like a solution. So:
- broker from rf keeps sending codes as-is
- add additional task that checks if code had been stable for long enough, flag it as such and trigger rules
- rpn_match will only work with flagged codes, pushing number of hits
- after rules are done, code is removed from tracking (for the time being)
Other option was to keep checking it in the rule itself, simply making _rpn_run=true after match did not work. It is probably slower though
Using |
Is this test using the string "test" as a boolean true/false change trigger? I tried with the rule set to |
|
Current implementation of 'rfb_match' marks code as used, so multiple rules or calling rpn.test with the same code won't work (why I wrote that note-to-self to fix that). Another issue is timing, since it won't see any matches outside of 2 second window, so your test won't ever reach Boolean value comes from 'test' variable. e.g. try running
|
|
Testing version 403e0c8. I thought the and |
|
I thought the way the rule worked was to only With respect to timing, if I use my two rules for monitoring the sensor as 4 second gap |
That was a typo :/ I was away from the original device, so I must've uploaded the correct version there (haven't heard complaints yet:). Condition indeed was Prints "hello world" every 3rd click of remote b/c code 'hits' reset back to 0 on the match. |
mcspr
force-pushed
the
rpn/rfb-codes-plus
branch
from
226308c
to
7b24bff
Compare
|
Some experimental stuff to support matching same code in multiple rules.
Will run a 2 second timer when code has at least N hits and continue only when timer had finished. Ordering is important though, so higher hits count needs to go first. After execution, it will 'eat' the code and force the rule after it to fail.
I've forcibly rebased the branch with the current |
|
I use Using the same rules as before (shown above) which looked for two different codes, I now correctly get the This will work perfectly for my application. The only issue I've found is if the rule were to be: You get the |
|
For reference, I 'Learnt' the two codes for a dummy I then changed the rules to those above. This switched the dummy |
|
Based on the original issue, knowing 2nd code would've helped :) Togging on a single one still only possible with the rule string. Also note that |
|
The original issue was that if you had an RF transmitter sensor that only produce a single code for open and close, due to the code being seen twice, the learnt switch just toggles immediately. Like you said, the The switching of |
|
I meant Which comes from the RF module. Rules fire simultaneously with that edit: btw, any thoughts on terminology used? 'hits', 'match', etc. |
- fix ifn to move stack instead of just moving values - fix parser accidentally treating things as float - fix parser empty space checks, treat newline as token separator - fix math operators not properly propogating the error - fix type capacity calculation for numerical conversions - add inf and nan operators - add u and i suffixes for dot-less numbers, makes expression push unsigned or int - support escaped characters in strings This also makes strings in-place, by appending a single character at a time, *possibly* slowing them down.
|
Is there a standard terminology for multiple triggers? |
|
Count might work.
|
|
Is there anything else you would like me to test while I have my development setup running? If not, I'll look to add the SRX into one of my 'in use' boards and run the RPN rules as is and update if needed when it's merged with the main Dev code. |
|
Nothing comes to mind so far, thanks! |
|
Hm. While looking at !rfb_direct vs. rfb_direct modes, I remembered that we actually have more than 1 protocol available. I'll change the Debug log codes above use a single protocol - 2nd byte is always the same ( |
|
Smallish changes based on the #2335
|
Testing #2274
Some new operators:
rfb_matchto trigger something on the exact N hits of the codetop argument is the code string, 2nd is protocol index, 3rd is number to compare with how much this code have been seen recently
rfb_sequenceto trigger something in specific sequence. needs 2 pairs of protocol number + raw code string.For example, using 'stock' RFBridge, where we only have a single protocol:
Meaning, we should set 'movement' variable to the current device's time when we see 00123456 the very first time.
Or,
To toggle 1st relay (index 0) when we receive the code twice
We also finally receive MQTT variables on connection by defaulting mqttSkipTime / MQTT_SKIP_TIME to 0. See topics in the rules section.
cc @davebuk from #2296