-
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,
Version 1.0 Pre-release Discussion
-
We're 60 days out from the 1.0 release date I gave earlier in this category. For about the next 30 days, I'll entertain new feature requests for anything you all feel is absolutely needed and not yet present for a 1.0 release, and you're going to have to make a strong case. Short of that, it will have to live on the wish list for a possible future release.
Identify and discuss in this topic, please... go!
-
The only thing that comes to mind is fleshing out the Docs (gonna be a fun chore!) and introducing more little (i) icons throughout the UI so that users can quickly jump to the related section of Docs for that panel/pane/action.
Right now, 21140 is like butter and I have no pressing outstanding Feature Requests to suggest.
Thanks for all the hard work you've put into making MSR as awesome as it is, even in beta! -
Virtual Devices as discussed here:
https://smarthome.community/topic/546/let-s-talk-about-msr-provided-virtual-devices-not -
possibly add future wind readings to weather entity like rain(1h and 24hr)
-
+1 on the docs. As a non-programmer, I struggled with what could probably best be described as the lack of prerequisite programming knowledge. I certainly would never expect a programming course in the docs, but examples in the "how-to" section will really help point people like me in the right direction. The installation (docker), logic, and concept sections were excellent for me, but I already had the basic gist of things from Vera Reactor.
+1 on the virtual devices.
Dashboard: I don't know if you view this as a separate but related project, but since MSR concentrates entities in one system, it would be a wonderful addition.
The only other thing I had thought of was a global "pause" button. I had to make lots of controller/device changes at one point, and I found myself looking for a way to put everything on hold while I reconfigured.
I just wanted to say thank you again for everything you have created. MSR has brought a level of maturity to my automation that was not previously possible for me to accomplish at my skill level.
-
Potential change: now that constraints apply to groups in a Rule's reactions, I see no value in keeping the Constraints as a separate subsection at the top level of a rule (that is, the section between Triggers and the Set Reaction when you edit a Rule). So, I'm thinking about removing them from here (any rules you have with constraints in this area would just get them restructured into a group constraint).
Thoughts?
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
On the constraints, once groups were introduced, I stopped using the constraint subsection unless it was a straightforward rule that did not require groups. I think opinions on this would vary based on the way people have settled in on rule construction and layout. Groups allowed me to consolidate my rule sets, so I have less use for them.
I thought of one other thing that would be helpful to me personally...
Would you or anyone else see any value in an "entity in use by" inspector/report generator? As things got more complex, I found myself doing a little digging when I needed to address a logic issue with an entity used in multiple sections of logic.
-
+1 on "Entity in use by" (or "watched by" or "referenced in") and see that as a possible extension of the objects we already see under ENTITIES. If, for instance, "Sofa Lamp" was referenced twice in the "Dim Lights" rule, it could list both occurrences as:
.references: Dim_Lights._Set_Reaction, Dim_Lights.Expr_DimLevel, where both are clickable links directly to those subsections of the referencing rule. -
This post is deleted! -
+1 Libra. A clickable link to take you to the location of use would be really nice.
-
@mikereadington said in Version 1.0 Pre-release Discussion:
+1 Libra. A clickable link to take you to the location of use would be really nice.
Although we have to acknowledge that expressions are able to reference entities without overtly looking like that's what they do - such as using loops and arrays - so it might be a technical challenge for MSR to pick up every single reference.
-
@toggledbits said in Version 1.0 Pre-release Discussion:
now that constraints apply to groups in a Rule's reactions, I see no value in keeping the Constraints as a separate subsection at the top level of a rule (that is, the section between Triggers and the Set Reaction when you edit a Rule). So, I'm thinking about removing them from here
Really?
Are these not two separate things with different uses.
I use the Contraints section of a rule as the main set of constraints / conditions for that rules Reaction / actions being run or not.
And then in some of my rules in its Set Reaction I also have further additional and different "Group Constraints" that are only evaluated and carried out if the Set Reaction actions were even run in the first place by the main constraints being met.
Personally I do not like at all this idea to remove the rules Contraints.
-
I have to strongly object to removing the rules Contraints section, which would be a major change to the concept of a rule and its work flow.
A logic engine has triggers then conditions then actions.
This is the same concept PLEG had and I used it for a decade.
We then asked you to give us the ability to have further additional conditions within the actions chain and you gave us that with Group Constraints.
The system is perfect as is.
What you are suggesting is to have triggers then actions with conditions mixed in with the actions.
Keep the main conditions in the separate Constraints section as they are now.
It's your project and creation and you can do with it what you like, but I won't be happy with this proposed major change if it happens.
-
@toggledbits , As you stated in another thread "Capabilities on Hubitat are free-form, and there's no indication which capability might be the most useful or primary". Could you add the ability for a user to manually select the primary capability for each Hubitat device? This would allow the Entities screen to display info in the primary value. If the Dashboard feature is added in the future then the Hubitat device should display correctly there also.( I also would like to request the dashboard)
-
This might be off topic and it also reveals my lack of programming skills. But I wounder how is MSR going to be installed, once it leaves beta? I use it on a stationary Windows 10, and the problem is if the power goes out. Then my PC reboots and I have to start the app and change catalog and finally execute "node app.js". I could install it on a RPi, don't know if it can work alongside and on the same RPi as I got Home assistant installed? Then it would start straight away, when the power gets back. To summarize, it's basicly two questions;
- In which ways are we going to be able to install and start up MSR?
- Is it possible to install MSR on a RPi that already is running HA? Or on a Home assistant blue (Odroid N2+)?
Another feature that would be nice is to have a optional setting of automatic updates.
Regardsless - MSR is a great (one of the best) contribution to the smart home community - at least for me. Great job!! -
@fanan The same thing happens with my RPI4 ... I have to start it manually...
-
There was a thread about having MSR auto start on a Pi. I set it up on my Pi and it did work MSR was started automatically after a reboot / power on.
https://smarthome.community/topic/439/how-to-auto-start-on-rpi-reboot?_=1621588014603
-
@fanan installing on a poi side by side with anything else will not hurt. On windows, just schedule it to run at startup via task scheduler.
-
@fanan At least initially, like many other projects, I expect MSR to be delivered in the following forms:
- Primary: Docker container. This facilitates not only a simpler integrated package to install that contains its dependencies, but also easily takes care of starting at boot on most systems. There are currently Docker containers available for Linux amd64 and armv7l (i.e. RPi4) architectures.
- Generic tarball. This will be a manual install for platform power users (Linux, Windows, and anywhere else nodejs and the companion dependencies can be installed by the user). There are available examples for automatic startup for systemd.
There's no reason you cannot install MSR next to Hass or anything else on a platform that allows you to install such things (clearly you're not going to install it on your Hubitat). I don't know anything about Hass Blue, but if it lets you install docker containers or the generic package, I see no reason you can't run them side-by-side.
@cw-kid said in Version 1.0 Pre-release Discussion:
@matteburk
There was a thread about having MSR auto start on a Pi.Slightly modernized version of the same here, should work on any platform that supports systemd: https://smarthome.community/post/8011
-
@fanan said in Version 1.0 Pre-release Discussion:
Another feature that would be nice is to have a optional setting of automatic updates.
I'll address this issue separately.
I think there are two interpretations here, so I'll start with the interpretation that I would more specifically call "unattended upgrades". Philosophically I'm opposed to unattended upgrades in all things, particularly on things that become "mission critical" in my environment. There is no "good time" for such updates except when I'm there to initiate them and recover if they come a gutser. History has shown that they otherwise will happen when I am far from home, usually for a sustained period and while Internet access is unavailable or inconvenient. When fully unattended upgrades to MSR happen, that will be your sign that I am no longer associated with this project.
The other interpretation is "push-to-start" upgrades from the UI. This is, frankly, a very low priority for me, and will not be something I entertain for 1.0, or likely 1.x. Docker containers are easily upgraded with a four-line script on command line-driven platforms, and still pretty painless in, for example, the Synology GUI (and still doable on the command line there as well). For users of the generic tarball, the detar and restart is even simpler. I understand that one click from the GUI would be easier, I don't disagree there, but keep in mind you've all been working in a mode where, for much of the history of its availability, MSR updates have come almost daily. That is not the norm, and I would not want it to be in production. In fact, production will go more to the model I use for R4V, where there is basically a very slow-moving release channel, a faster "stable" channel, and a bleeding-edge "latest" (what you have today).
The feature also introduces something that Reactor currently doesn't (on its own) require: access to a cloud infrastructure. Upgrades from within MSR require it to access cloud services, some existing, some not. This implies a lot of things, not the least of which include its security, its construction, and its cost to maintain and serve. If it gets done at some point, it will not come lightly, or easily, and it will likely be accompanied by license fees.
