OK. That's easy to address.
- Stop Reactor
- Delete the entire
storage/entitiessubdirectory (no others, just that one) - Restart Reactor
This will force all Controller-based entities to be rebuilt, like the motion sensor was, just in bulk.
Forum wide moderators
OK. That's easy to address.
storage/entities subdirectory (no others, just that one)This will force all Controller-based entities to be rebuilt, like the motion sensor was, just in bulk.
@cw-kid said in This trigger no longer working - complaining about the operator needing changing:
OK let me see if I can do that. You mean pressing the X here ? And then adding it back in to the trigger right?
No... Entities page... where you got the Copy Attributes output. There's a delete button there.
Delete the entity, then restart Reactor. It will come back, hopefully with binary_sensor capability.
I would delete the entity (using the delete button in the entity detail display), and the restart Reactor and see if it re-creates the Reactor-defined capabilities and attributes.
If not, look at the reactor.log file and see if it logged any errors related to VeraController.
Don't scorch the earth yet. Let's figure it out.
Post the attribute list for the device for starters. There's a Copy Attributes button in the entity detail. Use that, and paste the output here.
"Changing the operator on this condition will remove the non-default condition options currently set."
It's just telling you that the conditions options (under the dot-dot-dot button/icon) are going to be cleared because the operator is changing. That's because not every condition option is available for every operator. If you choose a Reactor-defined capability and attribute, it will recognize the operator's required type (so things like is TRUE and is FALSE will be allowed for attributes known to be boolean). When you use any extended attribute, like x_vera_anything.anything (the x_vera part being the clue that's an extended capability and attribute), that system's native type governs, and for Vera, that's a string, so is TRUE and is FALSE don't apply.
General recommendation is don't use the extended attributes when a Reactor-defined attribute is available.
To look beyond this, you'd need to post the attribute list for the device for starters. There's a Copy Attributes button in the entity detail. Use that, and paste the output here.
@cw-kid said in How to upgrade from an old version of MSR?:
Well that old Vera plugin still seems to work, it took a long time to trigger my new MSR rule however, even with the Site Sensor plugin set to a 60 secs interval. But it did eventually trigger the rule and send a TTS to my Google Home speak saying Emby sever was down.
Since you are hitting an endpoint in your local network, you can shorten the HTTP timeout by setting the Timeout variable on the SiteSensor device.
@cw-kid ZwaveJS is a piece of software, like reactor, specifically meant to provide Zwave software service. As such, it requires some usb key in order to work. No need to use home assistant. Nabu casa has some hardware as Zwave usb key that’s the best in town at the moment, known as ZWA-2. Together they make the same hw+sw as in Vera or Hubitat, but open and well maintained.
Install Zwave js ui, plug the usb key and you’re ready to go.
ZwaveJS UI => https://github.com/zwave-js/zwave-js-ui
Home Assistant ZWA-2 Zwave key => https://www.home-assistant.io/connect/zwa-2/
Docker is the way to go. I have two distinct hosts (one mainly as failover) and dozens of docker containers running alongside. The best feature is separation between them, so that if you mess with them, your system will run stable anyway and just the problematic containers will be impacted. Also, using docker compose file setup is a breeze. Not an easy learning curve, but doable.
@cw-kid nope, this is an hardware Zwave key from the guys working on home assistant that will work with anything you want and does not require home assistant at all. In fact, we’re running Zwave from ZwaveJS inside our own mini pc, no external hardware needed.
Awesome!
C