What Does This Symbol Mean?

I’m seeing this and recently this reactor failed to work after successfully working for a couple of days.


So my VeraPlus went on the fritz when trying to add in new sensors. Probably a memory issue. At any rate the lights went missing so they don’t show up in the Reactor as an activity device. I found the error and now to fix but how to clear up more memory? I saw some posts about that but haven’t been following along. Thanks.

for me it meant one on the condition variables went missing like if a device id changed

That’s the “trouble” flag, and it will be set when a device goes missing, or as @richie.digital said, an expression variable gets removed, and other things.

When that happens, a message is also logged to the event log in the Logic Summary, so just take a look there and see what it’s not happy about.

I got it figured out but it is not good…

Vera Support restored my VeraPlus and now all my reactors now say:

“Error executing function undefined(): s.match is not a function” and the switches and motion sensors for my garage lights still do not function.

Not cool on Vera’s part.

How to get my sensors going again? Will I need to re-program them?


Pull the hotfix branch version of J_ReactorSensor_UI7.js (right-click the link and choose “Save link as…”, save the file, then upload to your Vera via Apps > Develop apps > Luup files) and that should get you past the bump that’s keeping you from editing your broken sensors.

If everything goes to plan, the UI tries to show the old name of the now-orphaned configured device. This should help you get reconnected. It doesn’t automatically reconnect them–I thought that would be a little much–but it should show you what they were.

hey i have restored my vera plus now i get thei wehn i have run Lua : dofile("/etc/cmh-ludl/MySDc_Scene_KitchenMotion")

but it works in test code but not reactor

[MOD NOTE: This request was also asked by @richie.digital here: Reactor not doing run Lua. Please ask only once, and keep the question on topic for the thread. The question here is OT]

All is working now but I’m having issues keeping battery operated sensors alive so the lights come on hours later. Any suggestions for some lua to wake the sensors on a schedule?

The big thing about battery-operated sensors is that they wake themselves, but no matter how much Vera may scream at them, they won’t wake up until they’re good and ready.

I think most sensors have a configurable wake-up interval, which you can get to on the “Settings” tab of the device’s control panel in the Vera UI. Wake-ups aren’t intended to be a replacement for the sensor sending status updates when it has something to say, though, so I wouldn’t count on a smaller wake-up interval to do you much good (it may, at best, update Vera with correct status if it misses an update message, but it may not). Setting the wake-up interval too short will just kill your batteries.

It sounds to me like you may have mesh reliability issues with those devices, and if that’s true, really the only way you’re going to solve that is by getting your mesh healthy. You may need to install some hardwired Z-Wave devices along the path to those sensors to act as Z-Wave repeaters. My personal preference is the GE/Jasco Z-Wave duplex in-wall receptacles (that would be a good US choice, not sure about other locales).

1 Like

There are two door sensors here. Both are Monoprice / Vision Z-Wave Plus sensors. There are no hard wired Z-Wave devices between them and the VeraPlus but there are three in the garage beyond them. Additionally, the controller itself is about 20 feet away from each, one on the other side of the wall between the office where the controller is and the laundry room leading to the garage. The other is on the back door to the garage which is outside stucco wall and the door itself which is immediately adjacent to the laundry door. These devices are actually the closest to my controller in the entire mesh and should be getting a pretty decent signal.

I have an outdoor plugin GE switch for one of my landscape fixtures. Because it’s plug-in, it’s effectively hard-wired, and it itself will act as a repeater, and the anticipated radio performance would be on par with other hard-wired devices. Reality is a bit different. It is 14’ away from three Z-Wave light switches, just on the outside of the exterior wall opposite those switches. The exterior wall is stucco. Before I put in a hardwired switch on the exterior wall (about 3’ from the location of the outdoor switch, which lives in a thin but effective water-resistant plastic garden enclosure), I could rarely control the landscape fixture reliably–device not configured, retries, etc. Since installing the mid-way receptacle, no problems.

Consider that stucco is often applied over a galvanized wire mesh, which can make your house a big Faraday cage. Not only did I have to take this extra step for Z-Wave, but I routinely have problems hitting my local amateur radio repeater (tower distance about 5 mi) from inside the house on my handheld–notable performance difference if I have window glass in the line of sight vs stucco wall.

Also remember that most battery-operated devices are going to have much lower transmit power than the hardwired devices.

This reminds me, I have a GE/Jasco wired Z-Wave plug for the lighting on my Gazebo. This is about 20 feet from the controller too but about 90° relative to the door from the garage to the backyard; even then the door sensor is, of course, on the other side.

This morning, BTW, there was very little delay when opening the laundry door and the lights coming on. Maybe the devices just need to “settle in” so to speak?