-
Could the temperature values be pulled into MSR from one of these devices: OW-SERVER: 1-Wire to Ethernet Server
71.57 GBP OW server (Ethernet) OW server (Ethernet)Description The OW-SERVER is an inexpensive Ethernet to 1-Wire interface that is designed to efficiently monitor and control 1-Wire devices. The OW-SERVER will allow you to use industry standard Ethernet products (switches, hubs, etc.) to build the backbone of your 1-Wire based sensor / control...
Thanks.
-
I know I have mentioned this before somewhere, but i simply can't find the thread..
Plugins like Auto Virtual Thermostat and Delaylight from Vera/openLuup are functions that whould be lovely to have in MSR - is there any possibility to implement these in some way?
I could offcourse program them myself and copy them to where i want to use them, but if i'm not wrong that would be a fairly advanced ruleset that in any case would be beneficial to share with the community in some way when they are made and done.
-
Could MSR at some point support openHAB as a controller?
-
I'm probably going to release my first pass at the MQTTController for Reactor (aka MSR) this week. It doesn't yet intrinsically know about a lot of devices, but you can train it for pretty much anything, I think, and it would be great if a couple of our heavy MQTT users could help check it out and maybe help contribute some device templates.
I'm hoping to package it up for mid-week, assuming the rest of life stays on track.
Success factors for the test: solid familiarity with MQTT, a big mix of devices, and comfortable editing YAML (for creating the templates/mappings).
-
I've recently moved my Nest Thermostats from Vera to Home Assistant, using the official integration. This is a how-to migrate it completely on Home Assistant, thus retaining control and status in your Vera (i.e.: because you have code/scenes/Reactor rules/whatever to maintain - in my case it was all the above and more).
Prerequisite: goto https://github.com/dbochicchio/vera-VirtualDevices and install the virtual heater/thermostats files. Follow instructions, if in doubt.
First, go to your Vera, enter your thermostat Advanced Settings, under Params be sure to remove the plugin, by setting its value to 0. Then
change device_file to D_VirtualThermostat1.xml change impl_file to I_VirtualHeater1.xml change device_json to D_VirtualThermostat1.json change subcategory_num to 1 (if necessary)Repeat for other thermostats - you could use the first as master, so look for the doc for more info on this point. Be sure to remove the plugin from humidity sensors as well.
After the luup reload, hard refresh (CTRL+F5) your browser and then set all these variables to skip (we will not execute actions on setpoint/mode changes, we'll just save variables).
SetPowerURL SetPowerOffURL SetSetpointURLAt this point, the actions to change mode/setpoint will write your desired value to SetpointTarget and ModeTarget variables. We will use them in MSR to get the actions and execute them in Home Assistant.
Under MSR, be sure to write two rules.
One rule is watching for SetpointTarget and ModeTarget variables under the Vera Virtual Thermostat, to execute the actions on your thermostat.f70a6c94-df72-4b89-8d69-0edced1c5440-image.png
You'll need to translate the values from Vera's mode (Off, HeatOn, CoolOn) to HASS one (off, heat, cool). Since this thermostat is heating only, I'm just translating the ones I have. Repeat these steps for every device you have.
Then, you'll need to write a rule looking for temperature, setpoints, mode and so on. I have a unique rule to synchronize all of them, so I'm looking for humidity entity, temperature entity, and thermostat to update the Vera's variable. I have a set of expressions to translate to Vera's friendly variables:
730b32f0-d232-4bc4-9981-26dfaa00d56c-image.png
You'll need to just set the variables like this:
890083b3-ccd6-4039-99cb-1c90d64f00d5-image.pngVariables involved:
Service Variables Value urn:upnp-org:serviceId:TemperatureSensor1 CurrentTemperature ${{temperature}} urn:micasaverde-com:serviceId:HumiditySensor1 CurrentLevel ${{humidity}} urn:upnp-org:serviceId:TemperatureSetpoint1 CurrentSetpoint ${{setpoint}} urn:upnp-org:serviceId:TemperatureSetpoint1_Heat CurrentSetpoint ${{setpoint}} urn:upnp-org:serviceId:TemperatureSetpoint1 SetpointAchieved ${{setpointachieved}} urn:upnp-org:serviceId:TemperatureSetpoint1_Heat SetpointAchieved ${{setpointachieved}} urn:upnp-org:serviceId:HVAC_UserOperatingMode1 ModeStatus ${{modestatus}} urn:micasaverde-com:serviceId:HVAC_OperatingState1 ModeState ${{modestate}} urn:upnp-org:serviceId:HVAC_UserOperatingMode1 EnergyModeStatus ${{energymodestatus}}Just repeat these steps for every thermostat and you should be good to go. It could be adapted for a different mix of devices/systems, of course. I hope this will help someone else achieving the same results! Now we can control the thermostat from both point and everything is in sync!
-
I could not find a post or PR for this so apologies if it has been answered.
There seems to be a fixed width for the columns in the Entities page making it impossible to see the full Canonical ID of long ID's and a lot of white space in the Entity Name column.
I tried to adjust the width in Chrome and Edge without success, is it a feature or or am I doing it wrong?latest-22004-6d6c6b7 bare metal.
-
Following the docs:
each e in matchEntities({group:'groups>low_battery_entities'}): e.name each id in getEntity('groups>low_battery_entities').attributes.sys_group.members: getEntity( id ).name
In expressions; dynamic groups can be referred to in the groups key of the matchEntities() function, or by passing the group's canonical ID to getEntity(). The former is probably preferable, as it's much easier to read and understand what is going on.
Example in docs:I set up a Dynamic group:
- id: groups name: Dynamic Group Controller enable: true implementation: DynamicGroupController config: groups: "EzloDevicesNotResponding2": name: Ezlo Devices Not Responding select: - include_controller: ezlo - include_capability: x_ezlo_device filter_expression: entity.attributes.x_ezlo_device.reachable != trueBut when I try the Expression I get a compilation error
Log:
[latest-22004]2022-01-09T12:24:35.420Z <Engine:NOTICE> [Engine]Engine#1 expression testing has changed; recomputing dependencies [latest-22004]2022-01-09T12:24:35.421Z <Engine:ERR> [Engine]Engine#1: error evaluating expression testing: [ReferenceError]ReferenceError: Invalid reference to member name of ezlo>device_61baf610129e0725bd9f80f3 [latest-22004]2022-01-09T12:24:35.422Z <Engine:ERR> [Engine]Engine#1: expression: each e in matchEntities({group:'groups>EzloDevicesNotResponding2'}): e.name [latest-22004]2022-01-09T12:24:35.422Z <Engine:5:Engine.js:960> [Engine]Engine#1: path testing->testing [latest-22004]2022-01-09T12:24:35.422Z <Engine:CRIT> ReferenceError: Invalid reference to member name of ezlo>device_61baf610129e0725bd9f80f3 ReferenceError: Invalid reference to member name of ezlo>device_61baf610129e0725bd9f80f3 at _run (/home/homebridge/reactor/common/lexp.js:1411:31) at _run (/home/homebridge/reactor/common/lexp.js:1514:41) at /home/homebridge/reactor/common/lexp.js:1246:29 at Array.forEach (<anonymous>) at _run (/home/homebridge/reactor/common/lexp.js:1245:28) at run (/home/homebridge/reactor/common/lexp.js:1609:22) at Object.evaluate (/home/homebridge/reactor/common/lexp.js:1645:20) at Engine._eval_expr (/home/homebridge/reactor/server/lib/Engine.js:958:280) at Engine.notify (/home/homebridge/reactor/server/lib/Engine.js:644:142) at /home/homebridge/reactor/server/lib/MessageBus.js:106:223 [latest-22004]2022-01-09T12:24:35.424Z <Engine:5:Engine.js:1000> [Engine]Engine#1 set global testing; value=(object)(null)When not referring to e.name It's an array with three members
latest-22004-6d6c6b7 bare metal installation.
What I'm I doing wrong?
-
I can't post on the original thread its been locked for some reason
I am sometimes seeing this alert to do with this:
de844f5c-53db-4fc9-abac-a85606ea5e66-image.png
How do you fix it?
Thank you
-
@toggledbits Is there a way to get Current Alerts as an entity so I could monitor those and send notifications if needed.
My usecase is sometimes openLuup crashes and MSR picks that up pretty quick, sending a pushover notification to me would get my attention to restart it.
Of course there are many ways to monitor connectivity but since MSR already is doing that it would be neat to take advantage of it. -
Hi
We have a newish dev on the Vera forum making a few new plugins, which is good to see as we have hardly any 3rd party devs left any more.
He's created a nice little plugin here, that pulls down your current WAN IP in to a plugin device in the Vera UI7 gui.
I was under the impression that Vera plugin device support had to be explicitly added by the MSR dev ?
However it seems that this particular plugin has just bounced in to my Vera Edge Entities list after a Reboot of MSR and is showing this output, so appears to be just working.
x_vera_device.configured=false x_vera_device.device_number=162 x_vera_device.device_type="urn:nodecentral-net:device:ExternalIP:1" x_vera_device.failed=null x_vera_device.mapped_by="*" x_vera_device.mapped_class="generic_device" x_vera_device.parent_device=0 x_vera_device.room_id="0" x_vera_svc_micasaverde_com_HaDevice1.Configured="0" x_vera_svc_nodecentral_net_ExternalIP1.Current External IP="xx.xx.xx.xx" x_vera_svc_nodecentral_net_ExternalIP1.Icon="0" x_vera_svc_nodecentral_net_ExternalIP1.Last Changed="1641612887" x_vera_svc_nodecentral_net_ExternalIP1.Last Changed HR="1641612887" x_vera_svc_nodecentral_net_ExternalIP1.Last Checked="1641612887" x_vera_svc_nodecentral_net_ExternalIP1.Last Checked HR="1641612887" x_vera_svc_nodecentral_net_ExternalIP1.PluginStatus="Plugin variables being set up 2/2" x_vera_svc_nodecentral_net_ExternalIP1.PluginVersion="0.2" x_vera_svc_nodecentral_net_ExternalIP1.Previous External IP="0.0.0.0" Capabilities: x_vera_device, x_vera_svc_micasaverde_com_HaDevice1, x_vera_svc_nodecentral_net_ExternalIP1 Actions: x_vera_device.set_variable, x_vera_svc_micasaverde_com_HaDevice1.AllowPairing, x_vera_svc_micasaverde_com_HaDevice1.Poll, x_vera_svc_micasaverde_com_HaDevice1.Reconfigure, x_vera_svc_micasaverde_com_HaDevice1.Remove, x_vera_svc_micasaverde_com_HaDevice1.SetPollFrequency, x_vera_svc_micasaverde_com_HaDevice1.StressTest, x_vera_svc_micasaverde_com_HaDevice1.ToggleState, x_vera_svc_nodecentral_net_ExternalIP1.refreshExternalIPThanks
-
Hi
Is it possible to access the information that the MSR has about the last date and time that a device suffered a change? The information that appears in the Entities area?
dfd353df-15f9-44ef-bda3-8351363ea486-image.png
Use Case: I want to monitor all devices, and those that are not communicating/acting for more than 48 hours, take notice and action
Of course there are some that will not communicate by their nature, such as a water valve, so a list of exceptions would be created.
The principle is almost the same as Hubitat's WatchDog APP, but I want to have my own, and not be dependent on Hubitat's communication or action.
Thanks.
-
Hi, I am not a software developper so I apologise in advance...
MSR 20002 Docker on Raspberry PI 4I am using MSR and global expressions to control my house humidifier. To calculate the target humidity level, the outside temperature is used within a simple formula.
From time to time and for short period, the outside temperature, coming from a Hass sensor is showing a value "null" which is screwing up my target level. Ideally, I would like to retain the current value when the OutsideTemp is not available (i.e. null)
Here are my global expressions to perform this:
b8f39a70-d602-4adb-8bb5-30276cecc08a-image.png
OutsideTemp: Simply get the outside temperature (that is the one showing "null" from time to time.
CurrentHumid: Current house humidity
CalculatedHumid: This is where the target humidity is calculated. (Used to be 45 + round(OutsideTemp)
LowHumidity: This is the flag that tell the humidifier to start working.CalculatedHumid and LowHumid are use in a rule to update sensor in HASS.
In addiditon LowHumidity is used in 2 rules to turn the Humidifier on and off.At first, I was crashing MSR because CalculatedHumid was auto evaluating constantly. After a couple of attempt I disabled "Auto-Evaluation". From what I can tell, all is working fine which is a bit surprising considering what the documentation says about disabling auto-evaluation.
2 questions:
1- Since auto-evaluation is disable, how come the CalculatedHumid is still evaluating when the temperature changes?
2- Is there a better way to filter out a null value while retaining the previous valid value.
Thanks
-
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. -
The introduction of HA 2021.12 came with a breaking change to WLED whereby the lights no longer have the Service "wled.preset" or "wled.effect". The wled.preset service specifically allowed for the selection of a preset (specific color, effect, light intensity, etc) which was manually set up in the WLED application to use in automations. In MSR, to gain access to the service "wled.preset", a manual workaround was implemented which required the creation of a text file called local_hass_devices.yaml which then needed to be placed in the config subdirectory with some scripting that told the HassController class that the specific entity mentioned supports the wled service. More detail can be found in the prior post "MSR and WLED Presets". In 2021.12, however, to set up an automation Home Assistant, you must now select "select.select_option" as the Service with the entity being the specific WLED and the option being the actual name of the preset (versus the preset number required in wled.preset). Is there a way to implement the same Service in Reactor as that Service is not being provided as an option currently. Breaking change notes in Home Assistant simply say "The wled.effect and wled.preset services have been removed. For both services, full replacements are available as normal entities in Home Assistant."
-
I brought this over from Reactor for Vera back in the day. It's worked flawlessly, arming the lights for the xmas season which the various lighting rulesets point to. First night is the Friday after Thanksgiving and the last night is 01/07 as it covers the Russian Orthodox holiday.
This year, it stopped running at exactly midnight on 01/01.
ed10a6bd-2904-496d-91d2-19684f353ccd-image.png
Anything stand out in my logic that I've missed?
-
Hi, Power Switch and Dimmer don't change state, but seems only for this manifacture that I have:
Widom Dimmer and Double Switch.
On Ezlo plus they change correctly state, but in MSR Entities they are always on power_switch.state=false also If I put them ON with a reaction.EzloPlus - Msr v. 21351-a3aef - Synology Docker
[latest-21351]2021-12-18T15:48:52.612Z <EzloController:ERR> EzloController#ezlo ws_message handler failed: [ReferenceError]ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf [latest-21351]2021-12-18T15:48:52.612Z <EzloController:CRIT> ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf at Entity.setAttribute (/opt/reactor/server/lib/Entity.js:314:19) at /opt/reactor/server/lib/EzloController.js:1057:257 at Array.forEach (<anonymous>) at EzloController._update_entity (/opt/reactor/server/lib/EzloController.js:1001:55) at EzloController.ws_message (/opt/reactor/server/lib/EzloController.js:1386:815) at WebSocket.<anonymous> (/opt/reactor/server/lib/Controller.js:588:48) at WebSocket.emit (node:events:390:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1008:20) at Receiver.emit (node:events:390:28) [latest-21351]2021-12-18T15:49:41.720Z <EzloController:ERR> EzloController#ezlo ws_message handler failed: [ReferenceError]ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf [latest-21351]2021-12-18T15:49:41.720Z <EzloController:CRIT> ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf at Entity.setAttribute (/opt/reactor/server/lib/Entity.js:314:19) at /opt/reactor/server/lib/EzloController.js:1057:257 at Array.forEach (<anonymous>) at EzloController._update_entity (/opt/reactor/server/lib/EzloController.js:1001:55) at EzloController.ws_message (/opt/reactor/server/lib/EzloController.js:1386:815) at WebSocket.<anonymous> (/opt/reactor/server/lib/Controller.js:588:48) at WebSocket.emit (node:events:390:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1008:20) at Receiver.emit (node:events:390:28) [latest-21351]2021-12-18T15:50:22.258Z <EzloController:ERR> EzloController#ezlo ws_message handler failed: [ReferenceError]ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_61475325129e29124dfcd7e6 [latest-21351]2021-12-18T15:50:22.259Z <EzloController:CRIT> ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_61475325129e29124dfcd7e6 ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_61475325129e29124dfcd7e6 at Entity.setAttribute (/opt/reactor/server/lib/Entity.js:314:19) at /opt/reactor/server/lib/EzloController.js:1057:257 at Array.forEach (<anonymous>) at EzloController._update_entity (/opt/reactor/server/lib/EzloController.js:1001:55) at EzloController.ws_message (/opt/reactor/server/lib/EzloController.js:1386:815) at WebSocket.<anonymous> (/opt/reactor/server/lib/Controller.js:588:48) at WebSocket.emit (node:events:390:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1008:20) at Receiver.emit (node:events:390:28) [latest-21351]2021-12-18T15:51:09.464Z <EzloController:ERR> EzloController#ezlo ws_message handler failed: [ReferenceError]ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf [latest-21351]2021-12-18T15:51:09.465Z <EzloController:CRIT> ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf at Entity.setAttribute (/opt/reactor/server/lib/Entity.js:314:19) at /opt/reactor/server/lib/EzloController.js:1057:257 at Array.forEach (<anonymous>) at EzloController._update_entity (/opt/reactor/server/lib/EzloController.js:1001:55) at EzloController.ws_message (/opt/reactor/server/lib/EzloController.js:1386:815) at WebSocket.<anonymous> (/opt/reactor/server/lib/Controller.js:588:48) at WebSocket.emit (node:events:390:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1008:20) at Receiver.emit (node:events:390:28) [latest-21351]2021-12-18T15:51:09.514Z <EzloController:ERR> EzloController#ezlo ws_message handler failed: [ReferenceError]ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf [latest-21351]2021-12-18T15:51:09.515Z <EzloController:CRIT> ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf at Entity.setAttribute (/opt/reactor/server/lib/Entity.js:314:19) at /opt/reactor/server/lib/EzloController.js:1057:257 at Array.forEach (<anonymous>) at EzloController._update_entity (/opt/reactor/server/lib/EzloController.js:1001:55) at EzloController.ws_message (/opt/reactor/server/lib/EzloController.js:1386:815) at WebSocket.<anonymous> (/opt/reactor/server/lib/Controller.js:588:48) at WebSocket.emit (node:events:390:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1008:20) at Receiver.emit (node:events:390:28) [latest-21351]2021-12-18T15:52:02.630Z <EzloController:ERR> EzloController#ezlo ws_message handler failed: [ReferenceError]ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf [latest-21351]2021-12-18T15:52:02.631Z <EzloController:CRIT> ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf at Entity.setAttribute (/opt/reactor/server/lib/Entity.js:314:19) at /opt/reactor/server/lib/EzloController.js:1057:257 at Array.forEach (<anonymous>) at EzloController._update_entity (/opt/reactor/server/lib/EzloController.js:1001:55) at EzloController.ws_message (/opt/reactor/server/lib/EzloController.js:1386:815) at WebSocket.<anonymous> (/opt/reactor/server/lib/Controller.js:588:48) at WebSocket.emit (node:events:390:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1008:20) at Receiver.emit (node:events:390:28) [latest-21351]2021-12-18T15:52:02.680Z <EzloController:ERR> EzloController#ezlo ws_message handler failed: [ReferenceError]ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf [latest-21351]2021-12-18T15:52:02.681Z <EzloController:CRIT> ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf at Entity.setAttribute (/opt/reactor/server/lib/Entity.js:314:19) at /opt/reactor/server/lib/EzloController.js:1057:257 at Array.forEach (<anonymous>) at EzloController._update_entity (/opt/reactor/server/lib/EzloController.js:1001:55) at EzloController.ws_message (/opt/reactor/server/lib/EzloController.js:1386:815) at WebSocket.<anonymous> (/opt/reactor/server/lib/Controller.js:588:48) at WebSocket.emit (node:events:390:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1008:20) at Receiver.emit (node:events:390:28) [latest-21351]2021-12-18T15:52:51.736Z <EzloController:ERR> EzloController#ezlo ws_message handler failed: [ReferenceError]ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf [latest-21351]2021-12-18T15:52:51.736Z <EzloController:CRIT> ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf at Entity.setAttribute (/opt/reactor/server/lib/Entity.js:314:19) at /opt/reactor/server/lib/EzloController.js:1057:257 at Array.forEach (<anonymous>) at EzloController._update_entity (/opt/reactor/server/lib/EzloController.js:1001:55) at EzloController.ws_message (/opt/reactor/server/lib/EzloController.js:1386:815) at WebSocket.<anonymous> (/opt/reactor/server/lib/Controller.js:588:48) at WebSocket.emit (node:events:390:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1008:20) at Receiver.emit (node:events:390:28) [latest-21351]2021-12-18T15:52:51.764Z <EzloController:ERR> EzloController#ezlo ws_message handler failed: [ReferenceError]ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf [latest-21351]2021-12-18T15:52:51.764Z <EzloController:CRIT> ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf ReferenceError: Capability energy_sensor[electric_meter_kwh] not extended (ezlo>device_6187b203129e2912286888bf at Entity.setAttribute (/opt/reactor/server/lib/Entity.js:314:19) at /opt/reactor/server/lib/EzloController.js:1057:257 at Array.forEach (<anonymous>) at EzloController._update_entity (/opt/reactor/server/lib/EzloController.js:1001:55) at EzloController.ws_message (/opt/reactor/server/lib/EzloController.js:1386:815) at WebSocket.<anonymous> (/opt/reactor/server/lib/Controller.js:588:48) at WebSocket.emit (node:events:390:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1008:20) at Receiver.emit (node:events:390:28)Thanks in advance
-
Hi!
In Home Assistant I sometimes uses the TTS, either to my Sonos or Google speakers. With reactor in Vera I also use TTS.
But in MSR I can't select the TTS-service. It's simply not there. Am I missing something, or is this the case, so far?
Thanks!
/Fanan -
Hello,
Likely this is already in MSR, but I am trying to catch when Home Assistant crashes in MSR and power cycle the Pi it is running on. I have something causing instability in my Home Assistant and it becomes unresponsive once or twice a day. In MSR I get a red alert on the title bar and in the current alerts, but not seeing how I can use that as a trigger in MSR. What should I be monitoring?
Thanks,
Condition must occur after -restriction
-
@toggledbits noticed that in MSR you can define "only after" restrictions within the same rule, but not within the same rule set as is the case for RfV (one RS being similar to a rule set).
Is this intentional or have I misunderstood something?
-
Rule Sets in Multi-hub Reactor (aka Multi-system Reactor/MSR) are an organizational construct only and have no contribution to logic. ReactorSensors in Reactor for Vera (R4V) necessarily contributed to functionality at one time in the early days of Reactor, when it was strictly a rules engine and relied on Vera scenes for execution of actions (prior to version 2). It was also a manifestation of the requirement that all plugins are implemented as devices in Vera/Luup (and sensor seemed to be the right choice as a scene trigger). After R4V got its own activities, it maintained its sensor behavior and device structure for compatibility with the prior version, and that never changed.
It was never my intention to create full parity between Reactor for Vera and Multi-hub Reactor, although clearly they share a lot. Notwithstanding that, it is explicitly not true that Rule Sets and ReactorSensors are equivalent structures. They may share some attributes or uses for some people, but it was never my intention to have one be the replacement or analogue for the other.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@toggledbits okay, that was a bit badly formed that R4V RS = MSR rule set. Also, don't get me wrong that I would be driving a full parity of these two products.
I raised this up because I think in this case R4V implementation provides more value for the user, and one (at least me
) could create more flexible automations if this "only after" restriction could reference other rules at least in the same rule set, if not even broader scale. -
You can use a Rule State condition in the current rule, though, and reference that condition. While it's not as direct as picking a rule outside of the current rule, the effect is the same. If you want, though, you're welcome to open a feature request PR for direct selection of another rule.
-
Locked by toggledbits