@toggledbits said in Integrate UPS with MSR:
Fixed now, 22152 build of NUTController available for download.
Confirmed fixed. Thanks.
@toggledbits said in Integrate UPS with MSR:
Fixed now, 22152 build of NUTController available for download.
Confirmed fixed. Thanks.
Getting this error in the log when restarting Reactor after performing the installation steps for NUT controller. I am on Reactor 22149 installed on Ubuntu in Docker.
[latest-22149]2022-06-01T16:54:36.344Z <Structure:INFO> Structure#1 loading controller interface nut (NUTController)
[latest-22149]2022-06-01T16:54:36.345Z <Controller:CRIT> Controller: failed to load nut implementation /var/reactor/ext/NUTController/NUTController.js: [TypeError]TypeError: Incompatible base version; is 22125, requires at least 22145
[latest-22149]2022-06-01T16:54:36.346Z <Controller:CRIT> TypeError: Incompatible base version; is 22125, requires at least 22145
TypeError: Incompatible base version; is 22125, requires at least 22145
at Function.requires (/opt/reactor/server/lib/Controller.js:327:19)
at Object.<anonymous> (/var/reactor/ext/NUTController/NUTController.js:9:53)
at Module._compile (node:internal/modules/cjs/loader:1103:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1157:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:168:29)
at ModuleJob.run (node:internal/modules/esm/module_job:197:25)
at async Promise.all (index 0)
at async ESMLoader.import (node:internal/modules/esm/loader:337:24)
[latest-22149]2022-06-01T16:54:36.346Z <Structure:ERR> Structure#1 controller nut (NUT) skipped, implementation could not be loaded.
edit: Fixed in build 22152. See below.
@toggledbits said in Integrate UPS with MSR:
I use NUT on Linux (and I have a Reactor controller for it that I can publish). I know nothing about it on Windows.
I would be interested in trying out the NUT controller if you publish.
@snowman said in Strange MSR behaviours after NAS reboots:
Interestingly, everything seems to be working like it should even if I don't do anything. Which is weird.
So everything ends up working but the visual errors persist? It would be unsettling seeing all those errors even though it works fine.
My guess would be that home assistant is still loading when MSR starts and MSR is not seeing all the entities initially.
Not sure what else to try as you already commented out the Influx. Maybe back up your MSR files and try a fresh install.
The logs dont say anything else? If not I dont know and you might have to wait for @toggledbits
Maybe the logs will have a clue? The other day I moved HA to a new computer and MSR was trying to connect to the old machine and MSR would not load. Sure enough the logs indicated that MSR could not connect to HA. Fixed that and all was well.
Is it marked as failed in z-wave (z-way?) server? If you can reset the device without excluding it, I think you can use the replace failed node operation on the z-way server control section.
This is off topic to the original post so maybe it should be moved but it is directed towards the Home Assistant event_targets discussed above.
I defined an event_target in my system for emulated roku that looks like this:
event_targets:
"LR_Emulated_Roku_Home_Keypress":
name: "LR Emulated Roku Home Keypress"
capabilities:
- button
events:
- event:
event_type: "roku_command"
data:
source_name: "LR_Roku"
type: "keypress"
key: "Home"
response:
"button.since":
expr: "time()"
"button.state": true
This works great, detects the event and stores the time and True in the respective button entity attributes. However upon restarting MSR the values of the button entity attributes clear to null (e.g. button.since=null).
Is this expected behavior or should these values be maintained on restart?
I was messing around with this and I think there is an indentation issue starting at line 8. See below for what indentation worked for me.
event_targets: # this section starts the event-receiving entities
"my_virtual_entity_id": # Assign an ID to your entity; each entity must have a unique ID
name: "My Entity Name" # This is optional but recommended, so you have a friendly name
capabilities: # define an array of capabilities to be modified by the event
- capability_name # first capability
- capability_name # second, etc., as many as you need, but always at least ONE
events: # define an array of events that modify capability attributes on the entity
- event: # start of an event; each element of the events array begins this way
event_type: "type of HomeAssistant event"
data: # optional section, if further matching to the event data is required
data_field: "data_value" # data field to be checked/matched to data_value
data_field: "data_value" # as many as you need, but each data_field must be unique
response: # begin the (required) response section for handling the event
"capability.attribute":
expr: "expression" # expression to get attribute value from event data
# repeat "capability.attribute" section for all attributes modified by the event
It appears from the Nest- Home Assistant docs that the doorbell generates a nest_event (doorbell_chime). Unfortunately I do not believe there is any way for MSR to see these events. I have brought this up previously with respect to Emulated Roku. My work around is to use a native HA automation to detect the event and trigger a helper object that MSR can see, in my case I place the text of the event in a input_text helper which MSR can see.
@toggledbits said in Change in Plans (Don't Panic):
Maybe once I get the ZWaveJS interface fleshed out
Curious about progress on this. I was just messing around with ZwaveJS today and was thinking of utilizing it to move all my zwave devices from openluup+zway to HA+ZwaveJS. Obviously a direct ZwaveJS interface to MSR would be optimal.
Also is there any plans of a tool that might allow us to swap an entity reference in the rules? Moving zwave devices to ZwaveJS would require going through all MSR rules one by one and remapping to reference the ZwaveJS entity instead of the openluup entity.
I could definitely see it being useful for dashboards and also if an integrated controller does not provide the ability to create a virtual device.
@toggledbits So what would be the difference between MSR provided Virtual Devices and expressionless variables? Do you envision interacting with the virtual devices in MSR? Right now I use expressionless variables whenever I need to keep track of some value and I have no intention of needing to modify the value outside of logic. I use virtual devices both in openluup and HA when I intend to physically interact to change the value (or I have no other way of getting the value into MSR..cough cough HA event data generated by integrations that are not reflected in entities). I guess I am not seeing why MSR would need Virtual Devices to act as data containers when MSR already has data containers with expressionless variables.
There is a post from me above in this thread (sorry don't know how to link specific post) that explains how I got it to work. Have you tried that? I think the issue is synology gui does not support the correct type of volumes and you have to ssh into synology and run the correct docker command to set it up.
I think I had this same issue. If you copy the files in cmh-ludl from an existing openluup install into ' /OpenLuup/openluup-env' it should start right up.
I am using virtual machine manager on synology to host a Debian 10 VM. Works well.
@toggledbits Success! When pasting into Notepad++ I had to edit the line endings to (LF) and I also had to change the ID from "hass>media_player.lr_mibox" to "hass>media_player_lr_mibox".