-
I just gave up waiting for the HASS Z-wave.me integration to finish, and set up Zwave JS UI instead. In the same operation, all zigbee and 433 devices was moved from openluup to HASS as well, so all devices now have a new address.
I thought I saw some "replace device" function in MSR earlier, but now I didnt find it?
I've done a lot of the changes manually now, and removed openluup as a system, but at every restart I still get the warning/errors about the old units. I assume it's because rules ask for them? This is where that "replace this with this" would come in handy..
Right now, my problem is that the rules i did update doesn't pull any levers in HASS. If I go in and run the action line in the rule manually, it works, but only with the arrow button on the actual action, not the common arrow button in "set reaction".
Any tips/hints on making this transition easier is much appreciated. 🙂
-
Reposting here because core people seem to be here daily.
Hello Everyone,
I am using iPhone locator on Vera, and yesterday it stopped working. Looking at the logs, I can see the connection is refused, but nothing on my end changed. iPhone locator is really important in my particular setup, so I guess I have two questions.
Is it broken, or is it me?
I don't see anyone else saying there is an issue, but I am not sure how many people are still using it (or Vera for location) at this point. I installed it on a blank Vera test controller, same issue. It might be something with the iCloud account, but it works everywhere else.Is there something similar on another platform?
Mainly what I would like is the ability to force a poll of iCloud location on demand. I have a bunch of triggers setup, including magnetic sensors in my driveway to sense vehicles and determine if the motion is egress or ingress. These triggers in conjunction with MSR have been a great way to double check phone location, and I would hate to lose this functionality. It looks like HA might have something with "iCloud3". Is anyone using it?
Thanks,
Mike -
Hello,
Have a couple of areas defined by Long and Lat. In Entities I can see the values updating.Amy S9
hass>sensor_amy_s9_geocoded_location
"14320 NE 20th St, Bellevue, WA 98007, USA"
11:30:46 AMstring_sensor.value="14320 NE 20th St, Bellevue, WA 98007, USA"
value_sensor.units=null
value_sensor.value=14320
x_hass.domain="sensor"
x_hass.entity_id="sensor.amy_s9_geocoded_location"
x_hass.services=["sensor"]
x_hass.state="14320 NE 20th St, Bellevue, WA 98007, USA"
x_hass_attr.administrative_area="Washington"
x_hass_attr.country="United States"
x_hass_attr.friendly_name="Amy S9"
x_hass_attr.icon="mdi:map"
x_hass_attr.iso_country_code="US"
x_hass_attr.latitude=47.613968
x_hass_attr.locality="Bellevue"
x_hass_attr.location=[47.628323099999996,-122.14942209999998]
x_hass_attr.longitude=-122.16925
x_hass_attr.name="14320"
x_hass_attr.phone="null"
x_hass_attr.postal_code="98007"
x_hass_attr.premises="null"
x_hass_attr.restored=true
x_hass_attr.sub_administrative_area="King County"
x_hass_attr.sub_locality="null"
x_hass_attr.sub_thoroughfare="14320"
x_hass_attr.supported_features=0
x_hass_attr.thoroughfare="Northeast 20th Street"
x_hass_attr.url="null"
Capabilities: string_sensor, value_sensor, x_hass
Actions:In my rule they are not:
Entity Attribute: Amy S9 (hass>sensor_amy_s9_geocoded_location) x_hass_attr.longitude not between -122.183 and -122.166
-122.16925 -- false as of 11:32:38 AM
AND Entity Attribute: Amy S9 (hass>sensor_amy_s9_geocoded_location) x_hass_attr.latitude not between 47.603 and 47.617
47.613968 -- false as of 11:32:38 AM -
I would like to ask if this is possible and if others would find this useful.
I have multiple rules that check if lights are turned on manually and then have “Condition must be sustained for” xxxx amount of seconds then use the set reaction to turn off the light if it has not been shutoff. I like the UI when the rule is expanded that shows sustained time. (See Screenshot Below) Could a “Widget” have this information on the status screen that would show which rules conditions are waiting to come true with the sustained time? Similar to the Running Reactions widget.
Screen Shot 2022-10-04 at 7.44.09 PM.png Thanks
latest-22274
Synology Docker -
Iron: QNAP NAS
Running MSR and HAAS on Docker (QNAP Container Station)
Reactor (Multi-hub) stable-22203-81a2f3cc
Home Assistant Core 2022.6.7
Vera 1.7.5186 (7.31)
Config files are stored in shared volumes on the NAS.
Office light in example is joined to Vera-PlusHello all,
I decided to upgrade MSR to latest-amd64. It wasn’t until afterwards that I noticed all rulesets broken. So unfortunately I’m not sure if this was already broken before or I broke it after upgrading. Yes poor judgement on my part for being complacent.
Never the less, this is broken globally across all rulesets, even though I can see the triggers change to “True” (Turn green).
For this example, I have a boolean helper toggle in HAAS called “TV MODE HAAS SW”.
When toggled ‘on’, MSR should turn my Vera office light OFF and it doesn’t, but if I manually select the play button to the right of the line in the Set Reaction, it executes properly and turns off the Vera office light.
The MSR Rule does not have any Constraints set.
I can see in MSR it recognizes the state changes yet doesn’t execute the “Set Reaction”.
Any help greatly appreciated.
Log files from reactor.log and screen shots to follow:
Reactor.log when toggling the haas helper, Set Reaction doesn’t execute.
[stable-22203]2022-10-02T21:21:34.799Z <Rule:INFO> TV MODE ON (Rule#rule-l2hvuz8r) starting evaluation; because entity-changed Entity#hass>input_boolean_tv_mode [stable-22203]2022-10-02T21:21:34.800Z <Rule:INFO> TV MODE ON (Rule#rule-l2hvuz8r) evaluated; rule state transition from RESET to SET! [stable-22203]2022-10-02T21:21:34.819Z <Rule:INFO> TV MODE ON (Rule#rule-l2hvuz8r) evaluation complete [stable-22203]2022-10-02T21:21:34.820Z <Engine:INFO> Enqueueing "TV MODE ON<SET>" (rule-l2hvuz8r:S) [stable-22203]2022-10-02T21:21:34.835Z <Engine:NOTICE> Starting reaction TV MODE ON<SET> (rule-l2hvuz8r:S) [stable-22203]2022-10-02T21:21:34.835Z <Engine:INFO> TV MODE ON<SET> all actions completed.Reactor.log when manually triggering the Set Reaction with the play button which correctly turns off the light
[stable-22203]2022-10-02T21:23:25.035Z <HassController:null> HassController#hass: sending payload for power_switch.off on Entity#hass>light_office_86 action: [Object]{ "type": "call_service", "service_data": { "entity_id": "light.office_86" }, "domain": "homeassistant", "service": "turn_off" }When toggled ON
toggled_on.pngRule config screen
tv_mode_config.png -
Hubitat C7 = 2.3.2.141 AND 2.3.3.123
MSR in a docker = latest-22264-93bf3814 and latest-22266-88868fc0I'm curious if this is a bug or expected behavior. Unfortunately I don't know exactly when this began either. I have renamed a few devices over the course of the last few MSR builds, but never really brought it up before. Plus I don't rename devices too often. But I have a motion sensor right now that I renamed in Hubitat from "Office Motion" to "Living Room Motion" over 2 weeks week ago. Probably closer to 3 or 4 weeks now. I have restarted MSR several times since the rename, hard refreshed the browser, tried a different machine and different browser, and even an updated version of MSR. MSR is still showing the old name within the Entities section. I know I could rename it within MSR, but I would prefer to only have to rename devices in one location. I don't recall how long ago I started noticing this, which I know does not help at all.
-
Hey Patrick, this is probably a rather large request but it would be nice to be able to download a back-up of MSR through the UI similar to how we could do it with R4V. Beyond that maybe even having the ability to create a rule set that auto backups to a NAS would be even more useful! Currently I know you can just copy the complete reactor file from the machine MSR is running on but using the UI would make backing possible from anywhere and much simpler and quicker!
-
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.
Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed. -
Maybe a dumb question if I'm missing something obvious, but I checked the manual and searched the forum without finding anything relevant...
Can the Rule Sets on the left side of the MSR web UI be re-sorted? I just realized that it seems to be sorted with the newest ones at the top and I would prefer to have them alphabetical... and to have a multi-level tree with nested rulesets... but I'll settle for alphabetical for now if there's a way to do it 🙂
MSR latest-22266 / Raspberry Pi 4 / Docker
-
The reason for my question is a rather long story involving a virtual thermostat on my Hubitat and using InfluxDB and Grafana to graph the state of the thermostat.
The TL;DR version is that it would be helpful if I could send MSR expressions (variables) to InfluxDB. I don't currently see any way to do that, and if it isn't a current capability of MSR it might be useful as a future enhancement.
Long version: I have a rule in MSR that runs every minute to pull the thermostat information from my thermostat's cloud API. I parse the response into global variables, and then update a Hubitat virtual thermostat when those global variables change. I added the x_hubitat_Thermostat entity, along with selected capabilities, to my reactor.yaml in the InfluxDB section, 'default_capabilities', so the changes to the virtual thermostat get logged into the db.
It's working OK except when the API reports that the temperature has reached the setpoint but the system is still operating. For example, in the morning when the heat is turned up, the temp will climb until the setpoint == the temperature, but the system will continue heating for a while afterwards. It's a variable speed/heat system so it continues to run at very low output for quite a while after the temps match.
The issue I'm having is that when the temperature matches the setpoint, the Hubitat virtual thermostat switches to idle mode on it's own, despite the fact that the API is still reporting heating mode. When the virtual device sees that the setpoint has been reached, it automatically changes to idle, which makes sense as that's how you'd want a real thermostat to work .
I am working around this by having the rule that updates the temperature on the virtual device also update the operatingState. This fixes it, but for just a few milliseconds the virtual thermostat switches to idle before the rule sets it back to heat, and that state change shows up in Grafana.
If I could just directly log changes to the expressions to InfluxDB I could avoid the issue and get the same data into the database. Also I can see other applications for something like this with other APIs where MSR and InfluxDB could be used to log data without having any virtual device entities involved.
-
Hey Patrick, had to switch over my HA VM from VirtualBox to VMware since VirtualBox stopped playing well. Anyways I updated the IP address to the new VM IP and deleted the Long Lived Access Token and created a new one just in case (copy pasted the new token into the config file). Tried rebooting both the HA machine and the MSR one too and MSR is still not connecting. The only thing I have not tried yet is creating another controller entry, but I am worried it may create all new entities for everything forcing me to redo all my logic. Here are some logs:
[latest-22258]2022-09-20T21:17:24.749Z <HassController:WARN> HassController#hass websocket error during open/negotation: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:17:24.749Z <HassController:NOTICE> HassController#hass websocket to ws://192.168.8.113:8123/api/websocket closed during open/negotiation [latest-22258]2022-09-20T21:17:24.749Z <HassController:WARN> HassController#hass failed to connect/initialize communication: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:18:09.753Z <HassController:NOTICE> HassController#hass connecting to ws://192.168.8.113:8123/api/websocket [latest-22258]2022-09-20T21:18:24.761Z <HassController:WARN> HassController#hass websocket error during open/negotation: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:18:24.761Z <HassController:NOTICE> HassController#hass websocket to ws://192.168.8.113:8123/api/websocket closed during open/negotiation [latest-22258]2022-09-20T21:18:24.761Z <HassController:WARN> HassController#hass failed to connect/initialize communication: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:19:01.083Z <VeraController:INFO> VeraController#vera 0 dead entities older than 86400000s purged [latest-22258]2022-09-20T21:19:14.780Z <HassController:NOTICE> HassController#hass connecting to ws://192.168.8.113:8123/api/websocket [latest-22258]2022-09-20T21:19:29.785Z <HassController:WARN> HassController#hass websocket error during open/negotation: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:19:29.785Z <HassController:NOTICE> HassController#hass websocket to ws://192.168.8.113:8123/api/websocket closed during open/negotiation [latest-22258]2022-09-20T21:19:29.785Z <HassController:WARN> HassController#hass failed to connect/initialize communication: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:20:24.791Z <HassController:NOTICE> HassController#hass connecting to ws://192.168.8.113:8123/api/websocket [latest-22258]2022-09-20T21:20:39.813Z <HassController:WARN> HassController#hass websocket error during open/negotation: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:20:39.820Z <HassController:NOTICE> HassController#hass websocket to ws://192.168.8.113:8123/api/websocket closed during open/negotiation [latest-22258]2022-09-20T21:20:39.820Z <HassController:WARN> HassController#hass failed to connect/initialize communication: [Error]Error: Opening handshake has timed out -
Patrick,
I've just imported a large set of rules from Vera, and I had already played with creating rules in MSR that are mixed throughout the existing Vera rules. Is there any sort of way to "find/replace" in MSR, so I can find all matches to the old rules and replace them with the new ones? -
Patrick,
Yesterday I migrated a large luup Reactor group over from Vera to MSR, following the directions to importing it from Vera in the documentation. One of the odd things in the migration was the conditional rules for House Modes. Many of my rules had conditions such as "House Mode is any of Home, Night, or changes to Away.The way the import did it was changes from 1,3 to null. This importation did not seem to trigger rules correctly.
I was able to fix all the instances by creating multiple triggers in a group:
Entity Attribute: House Mode (vera>housemode) x_vera_housemode.mode contains home
OR Entity Attribute: House Mode (vera>housemode) x_vera_housemode.mode contains nightIs this what you are expecting in importation?
-
Good morning all,
This weekend I've been playing around with Home Assistant as a replacement (long term) for my aging Vera platform. I'm pretty amazed how much more capability it has. On the other hand, the sheer amount of variables it pulls in from devices is massive.In any case, I have added Google Calendar into Home Assistant for things like Federal Holidays and my daughter's school calendar. It connected to them without issue, which I had been having problems with in Vera an GCal3.
I connected MSR to Home Assistant, so I can start using some of the systems I've integrated into Home Assistant in MSR, and continue migrating my luup Reactor rules over to MSR. Now I'm trying to create a rule based on if today is a Federal Holiday or not. Reactor sees the calendar just fine, however, for whatever reason, it's not pulling data for today, but the next event, which in this case is Columbus day, three weeks away. The attribute that is pulling this is x_haas_attr.message.
I tested with my daughter's school calendar, and it did have an entry for today, and none of the other values seemed to be different, such as a "true" or something to tell me there is an entry.
a8478a6e-d8eb-4572-ac84-c94ff012a1ec-image.png
60632486-e80b-4f0f-aed9-dc67113689a4-image.png
ab04cd0f-f849-4e14-be7d-f4c00735da77-image.png
The only thing I've been able to come up with, is there is a start_time attribute, which shows the date as 2022-10-10 00:00:00
1cbe4526-7f63-4329-a088-b331f1d03376-image.png
The only thing I can think of is there might be a way to compare the current system date to that date, but I can't seem to figure that out in MSR.
Has anybody done this? Any suggestions?
-
I started kicking around the VEC last evening, was cut short, and dug in a bit more this morning.
My reactor.yaml:
d3df4d99-aa7f-4b8b-8fb9-5a6c615daad9-image.png
I verified the yaml is good at https://yamlchecker.com/
What I'm seeing in MSR:
0f89ce8e-7abe-4779-baca-43123e030cf4-image.png
87560ded-7dfa-4340-8585-8be58ff22852-image.png
I believe I have followed all steps (standard disclaimers apply).
Anyone else started to tinker with this newness and, if so, what were your results?
-
Having just embarrassed myself to @toggledbits by asserting that the latest release somehow had a bug when in reality it was surfacing underlying issues with my approach to building out my rulesets and automations I wanted to ask the collective for their feedback on how they've designed their rulesets.
For me, I built out a list of Global Reactions that I commonly use. For instance, for mode changes I typically change the mode entity and write that mode to a variable for some future use. When building out a ruleset I just pull in that Global Reaction vs manually recreating the entity list as my ruleset Reaction. Example, for lighting:
270bbe18-9680-491d-81d4-20308a9fe63c-image.png
Each of these contains the appropriate group of lights to turn on/off, etc.
I also have what I've dubbed my "Armed for..." rulesets. These are rulesets that can be referenced as true or false in other rulesets. Example, for my various lighting configurations in and out of the house I have these:
0d9f55d4-5d5d-42e2-a83c-8afa95df08fb-image.png
I think this is resulting in reactions stomping on other reactions creating race conditions that result in things looking like they're working when, in reality, they're one restart away from disaster.
So how are you all designing your superstructure, if you will, at a high level?
-
Maybe more of a cosmetic issue, but certain entities could be hidden from entity actions as you cannot set any meaningful action? See Vera as an example:
Screenshot 2022-09-16 at 15.11.29.png
vera>system is then obviously a different story and should be there
-
Hi @toggledbits,
I have a bridge consuming Vera's variable using the MQTTController in MSR, and I've noticed that after I've updated to the latest version (22257), some variables are not echoed. I've already tried to reboot MSR, with no luck.
These variables are under urn:smarthome-community:serverId:Vacuum
0fe837ed-3a29-4d5d-a06c-445981d44e13-image.png
A trace via MQTT explorer:
cf919028-4f7b-4761-b99a-c3943945704a-image.pngMy config has just exclude_capabilities: [] and it was working OK before the latest build. Even /query command doesn't seem to retrieve all the attributes. The values are retrieved correctly from the Vera controller, and I could use them in MSR, they're just not echoed to the bridge. Thanks!
-
Good morning all,
I"m working on converting my luup Reactor scenes over to MSR, so I can eventually introduce an Ezlo plus into the mix and not loose all the work I've done with Reactor. If nothing else, this should free up some resources on my aging Vera Plus, and maybe speed up some functions. Maybe that's just wishful thinking.In any case, I'm moving move my first Reactor set, which is a set of rules to control the blilnds/window coverings in my home. I have two types of blinds:
iBlinds retrofit motors (IB2.1-ZWx) version from late 2019.
Bali roman shades with factory installed Somfy CSZ1 Z-wave motors.I'm setting up reactions for both types of window coverings. One of the problems I always had in Vera was with iBlinds, I had to do it by luup commands:
luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget="50" },316)The reason for this, is that the open position was 100%, and the close position was 0%. In other words, the blinds were closed one way 100% an closed 100% the other way. I've been informed by iBlinds support that even in Ezlo, they still do it this way, which is different than most other Z-wave controller manufacturers. I'm not sure how the others do it, but some how "open" is right in the middle (50%).
So, in MSR, i can still set the Dimming1.SetLoadLevelTarget to 50, but I also noticed some other commands I haven't seen before in Reactor
3cdeeb89-5986-45bc-8a3b-79067050a22c-image.png
Is there some way in MSR to set that middle value to 50% so I can use cover.open? The command cover.close works as expected, so I'm wondering how I might use that cover.set.
Thanks for any advise.
-
I configured OWM Weather on MSR (latest-22257-dd9b9271), created an account with OWM, generated an API key, put the key in the yaml file, and I’ve waited over a day now. OWM Weather shows as up on the the Controller Status widget.
I’ve tried to create a trigger or constraint to use the data, and nothing is really showing up.
5B8611C1-33D0-4D3C-B507-7383CB81E25A.jpeg
I only have a free subscription with OWM, but I was expecting some data.
Is this expected behavior (i.e., still in development), or do I do more configuration other than the .yaml file?’
I still am able to pull Weather data through Dark Sky in my Vera plus controller, however, I know that will no longer work at some point.
Delays not working as expected
-
I seem to be having some issues with delays, so I set up a test as follows:
If the second rule is disabled, the first rule works as I expect - when motion is detected in the Hall, the Hall lamp switches on and then off again 10 seconds later.
With both rules enabled - when motion is detected in the Hall the Hall lamp switches on, but then if motion is detected in the Dining room, the Dining room lamp switches on, but the Hall lamp does not switch off after the 10 seconds , but after the 30 seconds when both lamps switch off at the same time.
Is this a bug, or just my understanding of how it should work?
-
You've screen shotted the rules without showing the delays. I can't tell what delay option you've chosen and how you've set it up.
-
Not sure I understand what you mean by delay option. Is there something else I should be setting?
-
OK. one aspect of the circumstances you describe could be a bug, and I will dig into that.
But the way you are approaching solving your problem is, I'm guessing, not really what you want. I think what you really want is that the light remain on as long as the sensor continues to indicate there is motion in the room and then turn off X seconds after no motion has been detected. This is the purpose of "delay reset" on the "Follow" output mode. You would then turn on the light via the SET reaction, and turn it off via the RESET reaction. No delay in the actions; just one action in each reaction (light on or light off).
The way you've implemented this with pulse output and a delay on actions, the lights will go on when motion is first sensed, but will go off at the prescribed time later whether you are still in the room or not, whether the motion sensor trips more or not. This may be, in part, contributing to your unexpected behavior. I'm going to dig deeper on specifically what you've done, because at the very least, it would be my expectation that your 10-second delay ended on time, but that would also depend on if you have anything in the reset reactions (do you?), and if any motion was sensed on the 10-second rule after the 3-second pulse, that would cause the SET reaction to re-fire and restart, eliminating the previous delay and starting a new one. So the test needs to be done very carefully, and if the two motion sensors are in close proximity or other people are moving in the area of either as well, there's ample reason to see how the delay could be cancelled and restart. Another reason not to use pulse and action delays.
-
Ok. Thanks for the explanation. You guessed right about how I want it to work. I'll try using "delay reset" on the "Follow" output mode instead.
I was careful about how I did the test and have just carried it out again. There is nothing in the reset reactions of either rule and I made sure not re-activate the motion sensor associated with the 10 second rule after the 3 second pulse. I'm the only one in the house at the moment, so no-one else interfering with the test.
It's always the case that the first timer does not end on time once the second timer is started. -
Cool. I'll see if I can reproduce those conditions in my test setup. If it's that predictable, should be no problem.
-
OK. I found it. Simple, stupid mistake, will be fixed in today's daily build. It's PR#64.
-
That's great that you found it.
I modified both my test rules to use the "delay reset" on the "Follow" output mode and changed the Set Reaction to switch the lights on and the Reset Reaction to switch them off again (much better way of doing it). Unfortunately, it hasn't fixed the problem, so I'm guessing the error you found affects this way of doing it as well. Will wait for the next daily build and test it again.
-
Can you post some screen shots of your work? Remember to show everything!
The action (reaction) delays are entirely different from the condition-based delays.
-
Ok, so this is how the rules for Delay1 and Delay 2 are now setup.
Each rule works perfectly fine when run on its own. The problem I have now is when one runs at the same time as the other.
To prevent any conflict, all my other rules in MSR are disabled, as are my Reactors in Vera.
In the following screenshot, Delay 2 (20s) is started and shortly after Delay 1 (10s) is started. Delay 1 completes first and its associated lamp switches off. Then Delay 2 completes but its associated lamp remains on.
What can't be seen in the screenshot is as well as the text being green for Delay 2 the whole box is also flashing green.
Everything works ok, except the lamp does not switch off after Delay 2 completes.
As can be seen from the logs, Delay 2 <Reset> does not occur.
2021-02-27T01:31:12.388Z Engine:INFO Delay 1<SET> all actions completed.
2021-02-27T01:31:29.320Z Rule:INFO Rule#rule-klmc7wxx (Delay 2) reset.
2021-02-27T01:31:29.328Z Rule:INFO Rule#rule-klifbnfi (Delay 1) reset.
2021-02-27T01:31:29.332Z Engine:INFO Enqueueing "Delay 2<RESET>" (rule-klmc7wxx:R)
2021-02-27T01:31:29.333Z Engine:INFO Enqueueing "Delay 1<RESET>" (rule-klifbnfi:R)
2021-02-27T01:31:29.334Z Engine:NOTICE Starting reaction Delay 2<RESET> [RuleReaction#rule-klmc7wxx:R]
2021-02-27T01:31:29.336Z Engine:NOTICE Starting reaction Delay 1<RESET> [RuleReaction#rule-klifbnfi:R]
2021-02-27T01:31:29.357Z Engine:NOTICE Resuming reaction Delay 2<RESET> from step 1
2021-02-27T01:31:29.359Z Engine:INFO Delay 2<RESET> all actions completed.
2021-02-27T01:31:29.431Z Engine:NOTICE Resuming reaction Delay 1<RESET> from step 1
2021-02-27T01:31:29.433Z Engine:INFO Delay 1<RESET> all actions completed.
2021-02-27T01:31:57.809Z Rule:NOTICE Rule#rule-klmc7wxx configuration changed; reloading
2021-02-27T01:31:57.812Z Rule:NOTICE Rule#rule-klmc7wxx stopping rule
2021-02-27T01:31:57.819Z Rule:NOTICE Rule Rule#rule-klmc7wxx stopped
2021-02-27T01:31:57.820Z Rule:INFO Rule#rule-klmc7wxx (Delay 2) started
2021-02-27T01:32:07.911Z Rule:INFO Rule#rule-klifbnfi (Delay 1) triggered!
2021-02-27T01:32:07.915Z Engine:INFO Enqueueing "Delay 1<SET>" (rule-klifbnfi:S)
2021-02-27T01:32:07.916Z Engine:NOTICE Starting reaction Delay 1<SET> [RuleReaction#rule-klifbnfi:S]
2021-02-27T01:32:07.979Z Engine:NOTICE Resuming reaction Delay 1<SET> from step 1
2021-02-27T01:32:07.980Z Engine:INFO Delay 1<SET> all actions completed.
2021-02-27T01:32:24.901Z Rule:INFO Rule#rule-klifbnfi (Delay 1) reset.
2021-02-27T01:32:24.905Z Engine:INFO Enqueueing "Delay 1<RESET>" (rule-klifbnfi:R)
2021-02-27T01:32:24.906Z Engine:NOTICE Starting reaction Delay 1<RESET> [RuleReaction#rule-klifbnfi:R]
2021-02-27T01:32:24.974Z Engine:NOTICE Resuming reaction Delay 1<RESET> from step 1
2021-02-27T01:32:24.975Z Engine:INFO Delay 1<RESET> all actions completed.
2021-02-27T01:32:29.114Z Rule:INFO Rule#rule-klmc7wxx (Delay 2) triggered!
2021-02-27T01:32:29.124Z Engine:INFO Enqueueing "Delay 2<SET>" (rule-klmc7wxx:S)
2021-02-27T01:32:29.125Z Engine:NOTICE Starting reaction Delay 2<SET> [RuleReaction#rule-klmc7wxx:S]
2021-02-27T01:32:29.175Z Engine:NOTICE Resuming reaction Delay 2<SET> from step 1
2021-02-27T01:32:29.176Z Engine:INFO Delay 2<SET> all actions completed.
2021-02-27T01:32:34.920Z Rule:INFO Rule#rule-klifbnfi (Delay 1) triggered!
2021-02-27T01:32:34.924Z Engine:INFO Enqueueing "Delay 1<SET>" (rule-klifbnfi:S)
2021-02-27T01:32:34.926Z Engine:NOTICE Starting reaction Delay 1<SET> [RuleReaction#rule-klifbnfi:S]
2021-02-27T01:32:34.973Z Engine:NOTICE Resuming reaction Delay 1<SET> from step 1
2021-02-27T01:32:34.974Z Engine:INFO Delay 1<SET> all actions completed.
2021-02-27T01:32:51.969Z Rule:INFO Rule#rule-klifbnfi (Delay 1) reset.
2021-02-27T01:32:51.974Z Engine:INFO Enqueueing "Delay 1<RESET>" (rule-klifbnfi:R)
2021-02-27T01:32:51.975Z Engine:NOTICE Starting reaction Delay 1<RESET> [RuleReaction#rule-klifbnfi:R]
2021-02-27T01:32:52.047Z Engine:NOTICE Resuming reaction Delay 1<RESET> from step 1
2021-02-27T01:32:52.049Z Engine:INFO Delay 1<RESET> all actions completed. -
On this one, I'm guessing you copied one rule from the other and modified it, yes?
Edit: interesting that two entirely different bugs would produce such similar result. In any case, they are PR#64 and 65. The latter will be fixed in 21058 (tomorrow). If you need to work around it, delete one of the two rules and create it entirely from scratch, not by copying (the bug is caused by a duplicate condition ID that appears both in the original and the copy).
-
Thanks for the fixes Patrick.
I've now tried them on my test rules and both (PR#64 and 65) work fine.
I've also updated all my imported rules to use the "delay reset" on the "Follow" output mode. These are all working now with the added bonus of being able to monitor the delays counting down.
Thanks again for the brilliant MSR.
-
Locked by toggledbits