@toggledbits
This may be a feature request, which would solve the dynamic IP issue in mentioned in my previous post. Would it be possible to use domain names in the allowed list instead of just IPs (I tried, doesn't appear to work)?

As I mentioned in the original post, I access MSR via the my Cloudflare domain name. Previous to this update, I was able to access it from anywhere. This lock down is probably a good thing, but it now creates a potential issue when I try and access MSR from my local network.

Cloudflare automatically updates the Origin IP of my network, which is the same as the IP my ISP assigns me. If I put my domain name in as an allowed source, then anytime my ISP reassigns me an IP address, then that source IP would be allowed.

My other option may be some sort of bash/cron script, but I'm not sure how successful it would be.

Okay, I determined the issue. I looked in the logs, and MSR is actually seeing the IP of the source host and denying the entry. I've added the assigned IP of from my ISP, as well as my work network to the allowed IP list. I can now access MSR from my workstation at work, as well as my iPhone with VPN to my home network turned on, and my local network as before. What I don't know about, is if my ISP reassigns my IP address, what I can do about it, as this could cause me to have to manually add that IP address every time it's changed. Historically, they haven't changed it often, but I may have to figure a way out to automatically update the config.

Good morning all,
I'm having an issue with the latest version of MSR. I'm unable to get past "Loading Reactor UI..."

I run a MSR image in Portainer on Proxmox as a Docker VM. This has served me well for about the past 18 months. Previously I ran MSR as a bare metal install.

To secure and access my local images, I run a Cloudflared LXC and run a Cloudflare tunnel. The Cloudflare tunnel for MSR points to my Proxmox server's local IP port 8554. I've used username/password since it became an option for MSR.

I've read the notes about new Access control and reverse proxies. I'm not sure that this new feature is what is causing my issue, but this is the only thing I can think of at the moment.

I also want to point out that if I access the site locally via IP, the site does load properly, albeit with a Not Secure warning:

Thanks in advance for any advice.

Running:
Reactor (Multi-hub) latest-26284-5f780cf0
ZWaveJSController [0.1.26048]

@Crille, thanks. I never noticed that box. Simple fix!

Good morning all,
I've ran into an issue a few times when a node has gone dead for whatever reason, and all other reactions are held up because a reaction is trying to run and won't end because of the failed node.

Specifically, I have z-wave blind controllers that are battery powered. Because they are battery powered, they don't always respond immediately. This becomes a problem when ZWave-JS updates, and the handshake between the update and the already included device fails. This doesn't happen often, but when it does, I have to go through the whole process of factory resetting the device and replace/including the existing device. This happened to me last night, and my whole home was held hostage by the one reaction that wouldn't run.

The reason it won't stop and continue is a Repeat condition I have in place that I got from @toggledbits quite a while back, that repeats the command until the position value registers what the it was ordered to be. Below is a screenshot of the reaction that is called from other rulesets. Note that there are two devices being called here, a grouping for a single room.

I think I need some sort of way to count the number of passes/attempts this makes, an then let it go on if it fails. I'm just not sure how I would go about that.

Any ideas?

@vezinpi
Thank you! That worked beautifully.

@toggledbits, thanks I did look for something like that, but I might be looking in the wrong place.

FWIW, my panel is an actual EyezOn panel (UNO IP Hybrid). I had an EnvisaLink 4 with a DSC panel that took a hit and I had to replace the unit. From a HAAS/MSR perspective, the interaction is identical.

Good afternoon all,
I have a question for anyone who has experience with MSR and Envisalink/EyezOn alarm panels. The integration works fine for the most part, but there is an oddity when MSR arms the system to away. I get a notification from in the EyezOn app that says the system was armed by the last user to DISARM the system. I'd like to arm it in a way that it arms by the the user that leaves the home, which triggers the automated Arm process. I tried to do it with a dedicated user code for MSR, but it doesn't arm with that user.

This is obviously more of an annoyance, as the alarm does get armed, but the audit trail is incorrect, so I don't know who armed it. Anybody have any insight?

running latest-26193-50401535 in Docker

Update. Worked perfectly. Thanks for setting me striaght!

Okay, I understand. For a minute I thought it there was a setting I needed to enable. I've set it up and I'll know if it works in the morning. Thanks for all the help.

Okay, thank you. That makes sense…. Other than deadband. What do you mean by that?

Okay, so maybe I'm missing something or not explaining my train of though here....

First, I'm not trying to control an exhaust fan, I'm trying to control the shower light. The exhaust fan has it's own built in sensor and . I'm using the humidity to determine that someone is taking a shower, so the light should remain on. When someone stops taking a shower, the humidity will drop (due to the automatic exhaust fan), and then the light can be turned off. I can't easily put a motion sensor in the shower, so the humidity sensor is the logical sensor. I've observed the values before, during, and after taking a shower, and generally, the humidity in that room is 30's or 40's, and when a shower is in play, it jumps up to the 70's or 80's.

I tried doing it with just one rule, but there really isn't a operand to change below a number. There is Changes from x to y, and then < or <=. If I just have a simple rule to say below 65%, then the light will go off before the humidity level rises. This is why I was trying to latch aspect, because generally when I step into the bathroom, I manually turn on the shower light, turn on the shower, finish, and inevitably the shower light get's left on, whether it's me or my wife.

I initially thought about the trend/time aspect, but I thought that for this purpose, that is actually over complicating things. All I really need to know is a) did the humidity level rise above point A, and b) did it drop below point B, in that sequence.

So, from my understanding, you are saying I just need to change the value fo the first condition to >= 65, and the second condition can stay at <= 65?

So, for some reason, my Latch method isn't working. I see the humidity go above 70, and I see the first condition go true. When I'm done showering, and fan evacuates the excess humidity, it drops back down and goes below 65, and that condition becomes true.

The second condition has the restriction that it must occur after the first condition is met.

I guess the second condition resets the Latched condition, so both conditions aren't true at the same time?

Is there another way to do a first condition, then the second condition that I'm missing?

@toggledbits said in Condition for trend:

VirtualEntityController can sample another entity's data and do time-series aggregation (moving average, rate of change, etc.).

Thanks for that. I wasn't familiar with that, and it sounds like what I was initially looking for.

I think I may have figured out a way...

If I use a Latch condition when the Humidity goes above 60, and then another condition when it goes below 45 (dependent on the first condition being true first), that should give me the result I'm looking for; that being the shower isn't being used anymore, and the shower light can be turned off. Am I correct in my understanding of how Latch works, in that that condition will stay true until the Set Reaction triggers?

Is there a way to set a condition for a trending number? I just installed a Zooz ZSE44 Temp/Humidity sensor in one of my bathrooms. I wanted to set a condition based upon how quickly the Humidity sensor reports the humidity level trending down (say after a shower).

If you look at the graph below from the device, you can see the humidity spiking at 5 am, then dropping, then spiking again, then dropping. I'm trying to set up a condition when the level trends up or down quickly.

@toggledbits said in Set reaction triggering wrong z-wave device:

The name is incorrect at ZWave-JS (on the node itself) if that's the case, so to keep your sanity later, make sure you go all the way back to the source and work your way forward from there.

I renamed the devices on the ZWave-JS UI, so i won't have the problem going forward. I'm still not sure how this all happened, as I did not experience this problem in years past. The only thing I can think of is there was some sort of glitch in an upgrade. I know I had to restore the Z-Wave JS UI to an earlier version back in October because of a change they made that broke window coverings, so perhaps during that restore something went wonky.

@toggledbits

Thank you. Perhaps the non-updating of the name was the root cause of my issue all along.

@toggledbits said in Set reaction triggering wrong z-wave device:

. Can you confirm that in the startup messages for Reactor, ZWaveJSController reports it is version as 25304

Yes, it shows up as 0.1.25304

So, you seemed to have hit it. There is a disagreement in the names in the Z-wave JS integration and the Z-Wave JS UI naming. I'm not sure how or when that happened, since I haven't touched the naming of these in at least 2 years.

The device that is 136 is truly the Front Porch Sconces. Everywhere in the HA dashboards when I click on the binary switch, it does turn it on. Same with 137 being the Soffit Lights.

It would seem it's getting the names from the ZwaveJS UI values, since they seemed to be off. I've gone ahead and renamed them in ZwaveJS UI to reflect the values in ZwaveJS. How do I get ZWaveJSController to update the names? They still show up as the incorrect name. I went ahead and restarted MSR, and the old naming is till persistent.

I also just noticed that if I performed an action from the Entities page in MSR fr 137-0, it's turning on 136-0 in HAAS. If I turn on 136-0 through entities, it's turning on 137-0 in HAAS. It would appear these devices are somehow switching actions, despite everything showing what they are.