[Solved] Local expression in Rule does not evaluate as they used to do

[MikeReadington]

Hi Everyone,

First post here, so hello everyone.

I had time today, so I figured I would get MSR up and running on my Synology Docker. Thanks to the discussions between Patrick and Libra, I had no issues with installation or configuration. I added the stand-alone test controller VeraTest to MSR, and it pulled all the entities on that controller without issue. After some poking around, I decided to add the VeraShop controller to MSR, and it only shows the following under entities.

house mode
Reactor System
user (User Names)
Vera System
VeraShop (reactor ID)

I thought that was odd because VeraTest worked fine.

When I switch to the VeraHouse or VeraTest controllers, all of the expected entities on that controller show up in MSR. When I switch back to VeraShop again, no entities other than what I listed above show up.

There are only two differences I can come up with between all three controllers.

1. VeraTest and VeraHouse are Vera Plus units, and the VeraShop unit is a Vera Secure.
2. VeraHouse is bridged to VeraShop to allow all of the devices on VeraHouse to show up on VeraShop.

Any ideas? I try to work through things myself, but I am stuck short of breaking the bridged system apart. I can certainly do that, but the units are still running my property, so it's the last resort.

Thanks again,
Mike

Edit: Clarification on switching controllers. I am not adding multiple controller, I am shutting down the container, editing the config file, and then starting the container to switch to the different controllers.

[toggledbits]

I have no idea how the bridge works or how it represents devices from other systems. What shows in Reactor is any device that is reported in a user_data request in the devices heading. If bridged devices are there, they should appear. If they are elsewhere, then they would not be expected to appear.

[MikeReadington]

I cleared the log and did a restart with a configuration file for each of the Veras. I can see where the error is, but I do not know what it means. I did not want to start a report on Mantis and add something that is not really a bug.

All bridging does is bring in the devices from the bridged unit into the "master unit?" to allow cross-Vera interaction. If you were looking at a "master unit?" Vera UI that has been bridged to another unit will see all of the devices from the bridged unit in the master's device list. That allows a user to interact across the units as if all the devices were paired locally to the master unit. While doing this is not exactly the norm, I don't think it's out of the range of what you would find within the Vera community. Larger homes or multiple buildings are usually the main reason people do/did this.

The way I see it is that MSR completely removes the need for bridging since all of the logic can be centrally located. While writing this, it occurs to me that I will have to break this all down and start clean anyway since most of my current Reactor logic interacts with devices brought in through bridging. <sigh>

Attached is what I see in the Reactor logs for VeraShop with the error and VeraHouse with no error. If the error is somehow tied to the bridging, maybe this post will help someone that has the same issue in the future.

Thanks,
Mike

[toggledbits]

Can you run the following request against the VeraShop system (put its IP address where indicated below) and either post the response on a PR or email it to me (address in my profile)?

http://vera-ip-address:3480/data_request?id=user_data&output_format=json

[MikeReadington]

I replied to an email you sent me with the output.

[toggledbits]

OK. The issue causing an error on VeraShop is that system is supplying a string containing JSON data instead of an actual array. I wonder if it's stuff being copied from the other system that it neglected to unpack? A related part of the structure that would normally accompany that array is also missing entirely, so I suspect it's all a bug in the bridging. I'll detect the anomaly and move on without the normal processing of that data (all related to geofences, by the way). I suspect it would make the Reactor for Vera plugin choke as well for the same reasons. After you update to today's build (later), you should get your devices on Shop.

[MikeReadington]

Thanks Patrick,

I did not have any issues with Reactor on my Vera in the ways I have been using it. The bridged devices do show up in Reactor, and they can both trigger conditions and react to actions. I don't know what you saw for geofence, but the only thing I use for location is amg0's find my iPhone.

I will let you know what I see when I update, but for me, it's clear the most efficient route forward is to start fresh and replace the bridging with MSR.

Thanks again, and I will keep an eye out for the docker container.

[MikeReadington]

Hi Patrick,

20174 fixed the issue. I now see the entities from both controllers while connected to the master controller.

Thank you!

[toggledbits]

Awesome.