Hi @toggledbits,
I have lots of logs with this:
<Engine:ERR> Assignment to alarm ignored -- expression-driven global cannot be set by assignmentAny hints to where look at to avoid this? Thanks.
Hi @toggledbits
I'd like to update my controllers with these new features, but I'm struggling to find any guidance in the docs - and in general to understand the context.
Could you please elaborate more? Thanks.
I have the following ACL defined:
groups: admin: users: - admin applications: true api_acls: # This ACL allows users in the "admin" group to access the API - url: "/api" group: admin allow: true log: true # This ACL allows anyone/thing to access the /api/v1/alive API endpoint - url: "/api/v1/alive" allow: trueAnd I have authenticated to MSR as "admin" user. However, I'm getting "access denied" when trying to access http://*******:8111/api/v1/log
So what I'm missing, is my ACL incorrectly defined?
Using build 24302 on Docker.
Thanks to @toggledbits for adding a custom CSS. I've started doing a darker Reactor style.
Here's the file: https://gist.github.com/dbochicchio/825098ac13b7f8cac22012eae37ff7ce
A couple of things are still too bright and I'll eventually catch-up. Just place it under your /config directory, naming the file as customstyles.css. Hard refresh your browser.
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
Hi
I have just connected a bunch of EzloPi controllers to MSR to import some ESP based devices etc.
They all seemed to have worked and imported in to MSR apart from I have one missing device. It is a Digital Gas Sensor device.
This is how that device looks in the Ezlo API.
Devices Info:
_id: "10696001" deviceTypeId: "ezlopi" parentDeviceId: "10696000" category: "level_sensor" subcategory: "" gatewayId: "457a5069" batteryPowered: false name: "Gas Sensor Digital" type: "sensor" reachable: true persistent: true serviceNotification: false armed: false roomId: "" security: "no" ready: true status: "idle" parentRoom: true protectConfig: "default"Items Info:
_id: "20696001" deviceId: "10696001" hasGetter: true hasSetter: false name: "smoke_density" show: true valueType: "substance_amount" scale: "parts_per_million" value: 2.7472610473632812 valueFormatted: "2.75" status: "idle"There is also an Analog Gas sensor that one did import in to MSR OK.
68d63dab-b871-4f44-912b-cf6e0b9eb4c6-image.png
Devices Info:
_id: "10696000" deviceTypeId: "ezlopi" parentDeviceId: "10696000" category: "security_sensor" subcategory: "gas" gatewayId: "457a5069" batteryPowered: false name: "Gas Sensor Analog" type: "sensor" reachable: true persistent: true serviceNotification: false armed: false roomId: "" security: "no" ready: true status: "idle" parentRoom: true protectConfig: "default"Items Info:
_id: "20696000" deviceId: "10696000" hasGetter: true hasSetter: false name: "gas_alarm" show: true valueType: "token" enum: 0: "no_gas" 1: "combustible_gas_detected" 2: "toxic_gas_detected" 3: "unknown" valueFormatted: "no_gas" value: "no_gas" status: "idle"And this is how this MQ2 Gas Sensor looks like on their dashboard:
Digital
cb77dfa3-4af5-4d06-9635-89207a716a89-image.png
Analog
4fb4da1b-e946-4b89-876c-bcd9f5699b6c-image.png
They have an EzloPi website here you can create your own sensor projects using ESP boards, which is very interesting stuff!
And I just wrote on the Ezlo forum here, how to connect an EzloPi controller to MSR.
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.A couple of things for you @toggledbits, since you mentioned that this release has new features and some tweaks are expected.
Local expressions cannot be deleted. Pushing the X button has no effect for me.
When cloning an entity action, the result is strange (first is cloned one, second is the original action):
a92ea094-9e2c-4aaa-bf47-2d07a6ffdbd0-image.png
When changing the action on the cloned element, the params are added to the original one. See screenshot:
92ac3011-83c8-466b-bd23-47d483ad7a52-image.png
Dark theme has a couple of strange contrasts. One is visible in the previous screenshots (white text on yellow background). Another one is in groups (blue text on blue background):
9b3c4988-53ef-44e6-9672-30e744cacb75-image.png
Overall, I found blue, yellow, red and green (in buttons and forms) to be too bright.
On the bright side:
I love the new script action: thank you! The dark theme is a great start to avoid getting blinded at night I promise I'll try very soon the new features around actions. Thanks!@toggledbits
I just upgraded to version MSR 24293, bare metal running on Fedora. Upon restart, I am getting a error banner:
I followed the new directions about npm
npm i --no-save --no-package-lock --omit dev
Any idea what the issue is?
Seems like switching the UI to the newly added dark mode (thank you for this) does nothing. The UI stays in light mode and only a few buttons turn into dark mode (see screenshot)
Things I have tried:
Hard refresh
Different browser
Different computer
Restarting Reactor
Failed troubleshooting attempts:
No errors in Chrome console
No relevant errors in Reactor log (can still PM the full log file)
Reactor version: latest-24293-ea42a81d
Hardware: Odroid N2+
Linux version: Ubuntu 24.04.1 LTS
3df2806f-9146-485b-9ec1-d056e91cefe5-image.png Dark mode enabled
ff823023-c079-4684-b01f-d6ac6527d31a-image.png Light mode enabled
Good morning,
I have a service MQTT service that needs a restart occasionally. The add-on (Smartbed MQTT) is for the smart bed base for my bed. It has a "safety light" that I can control from HAAS & MSR as a light entity, and also moves the head of the bed to a preset at bedtime, and then lies it back flat in the morning The problem is, from time to time, the light becomes "unavailable" Restarting from the Add-ons tab in HAAS always fixes it, but I should be able to detect when it happens when "light.tempur_pedic_safety_lights" is not true or false, i.e., unavailable.
What I don't know how to do is how to restart that service. Does anybody have experience in restarting add-ons from MSR?
Running:
Reactor (Multi-hub) latest-24212-3ce15e25 ZWaveJSController [0.1.24232]HAAS:
RPi5-64 (8GB) Core 2024.7.3 Supervisor 2024.08.0 Operating System 13.0 Frontend 20240710.0Hi!
Is it possible to generate two additional log files, the first being the replica of what is displayed on screen by the Rule History widgets and the other with Recently Changed Entities?
And could I configure the generation of one file per day, and delete the older ones? For example, store the last 5 days?
And being more ambitious, does Windget have an icon to open these TXT files in the navigated?
Well, we're approaching Christmas, so here's my request to Santa Claus @toggledbits 🙂
Hi @toggledbits
I'm working on a controller to generate llm response from a prompt in reactor. I have http response coming thru an http request action at the moment, capturing the response inside a local variable. So, it's practically sync.
I want to create a controller, so I don't have to rely on a proxy (and have a simpler architecture), and duplicate absurd http actions, but AFAIK in the current implementation, actions are async only. But if I have multiple requests going on, I cannot be sure what it's really inside an attribute. I also thought that something like a correlation id when sending the request could be used to identity multiple responses, but I wanted to double check with you before starting with something too complicated. I also noticed that some actions in home assistant (ie forecast) are sync and I'm wondering if you have any plan or hint to address this situation. Thanks.
Thanks.
@togglebits I am curious as to why the tilt_sensor.state (primary) = NULL. I believe it should show true or false. I have to use binary_sensor.state instead in my rules.
Again, not sure if this is related to Reactor/ZwaveJSController implementation or the actual Z-Wave JS UI docker version. I have copied, below, the attributes of the tilt sensor in hopes it can help.
Thanks in advance.
Reactor version 23302
ZWaveJSController version 23254
Z-Wave JS UI version 9.3.0.724519f
zwave-js version 12.2.3
@toggledbits I have noticed after upgrading both Reactor and ZWaveJSController to version 24257 that two of my devices/entities, TILT-ZWAVE2.5-ECO and Zooz ZSE18, had their entity re-named in an unusual way and also appears to be duplicated.
Reactor version 24257
ZWaveJSController version 24257
Z-Wave JS UI version 9.18.1
zwave-js version 13.2.0
Vestibule Motion Sensor State attributes/partial screenshot of entities it created. All entities have the same attributes.
motion_sensor.state=true x_zwave_values.Notification_Home_Security_Motion_sensor_status=8 zwave_device.capabilities=[113] zwave_device.endpoint=0 zwave_device.failed=null zwave_device.manufacturer_info=null zwave_device.node_id=23 zwave_device.valueId=[113,"Notification","Home Security","Home Security","Motion sensor status","Motion sensor status"] zwave_device.version_info=nullTilt Sensor Door State and Tilt Sensor Door State Simple attributes/partial screenshot of entities it created. All entities have similar attributes with exception of x_zwave_values.Notification_Access_Control_Door_State = 22 or 23.
tilt_sensor.state=true x_zwave_values.Notification_Access_Control_Door_state=22 zwave_device.capabilities=[113] zwave_device.endpoint=0 zwave_device.failed=null zwave_device.manufacturer_info=null zwave_device.node_id=24 zwave_device.valueId=[113,"Notification","Access Control","Access Control","Door state","Door state"] zwave_device.version_info=null tilt_sensor.state=true x_zwave_values.Notification_Access_Control_Door_state_simple=22 zwave_device.capabilities=[113] zwave_device.endpoint=0 zwave_device.failed=null zwave_device.manufacturer_info=null zwave_device.node_id=24 zwave_device.valueId=[113,"Notification","Access Control","Access Control","Door state (simple)","Door state (simple)"] zwave_device.version_info=null tilt_sensor.state=false x_zwave_values.Notification_Access_Control_Door_state=23 zwave_device.capabilities=[113] zwave_device.endpoint=0 zwave_device.failed=null zwave_device.manufacturer_info=null zwave_device.node_id=24 zwave_device.valueId=[113,"Notification","Access Control","Access Control","Door state","Door state"] zwave_device.version_info=null tilt_sensor.state=false x_zwave_values.Notification_Access_Control_Door_state_simple=23 zwave_device.capabilities=[113] zwave_device.endpoint=0 zwave_device.failed=null zwave_device.manufacturer_info=null zwave_device.node_id=24 zwave_device.valueId=[113,"Notification","Access Control","Access Control","Door state (simple)","Door state (simple)"] zwave_device.version_info=nullI'm slowly migrating all my stuff to MQTT under MSR, so I have a central place to integrate everything (and, in a not-so-distant future, to remove virtual devices from my Vera and leave it running zwave only).
Anyway, here's my reactor-mqtt-contrib package:
Contrib MQTT templates for Reactor. Contribute to dbochicchio/reactor-mqtt-contrib development by creating an account on GitHub.
Simply download yaml files (everything or just the ones you need) and you're good to go.
I have mapped my most useful devices, but I'll add others soon. Feel free to ask for specific templates, since I've worked a lot in the last weeks to understand and operate them.
The templates are supporting both init and query, so you have always up-to-date devices at startup, and the ability to poll them. Online status is supported as well, so you can get disconnected devices with a simple expression.
Many-many thanks to @toggledbits for its dedication, support, and patience with me and my requests 🙂
Hi @toggledbits.
After a couple of weeks, I noticed that my Remotec zrc90 isn't working as expected.
Scenes are working in ZWaveJS, but this device has a strange behavior: the scene change, but then it's set again to null. In Reactor, this remains null:
battery_power.level=0.7 battery_power.since=1725817957361 x_debug.dt={"description":"Scene master 8 button remote","model":"BW8510/ZRC-90US","default_name":"Scene master 8 button remote","manufacturerId":21076,"productType":0,"productId":34064} x_zwave_values.Battery_isLow=false x_zwave_values.Battery_level=70 x_zwave_values.Central_Scene_scene_001=null x_zwave_values.Central_Scene_scene_002=null x_zwave_values.Central_Scene_scene_003=null x_zwave_values.Central_Scene_scene_004=null x_zwave_values.Central_Scene_scene_005=null x_zwave_values.Central_Scene_scene_006=null x_zwave_values.Central_Scene_scene_007=null x_zwave_values.Central_Scene_scene_008=null x_zwave_values.Central_Scene_slowRefresh=null x_zwave_values.Manufacturer_Specific_manufacturerId=21076 x_zwave_values.Manufacturer_Specific_productId=34064 x_zwave_values.Manufacturer_Specific_productType=1 x_zwave_values.Version_firmwareVersions=["1.1","1.1"] x_zwave_values.Version_hardwareVersion=3 x_zwave_values.Version_libraryType=2 x_zwave_values.Version_protocolVersion="4.5" x_zwave_values.Wake_Up_controllerNodeId=1 x_zwave_values.Wake_Up_wakeUpInterval=0 zwave_device.capabilities=[91,114,128,132,134] zwave_device.endpoint=0 zwave_device.failed=false zwave_device.generic_class="Remote Controller" zwave_device.impl_sig="24242:1:22315:1" zwave_device.is_beaming=false zwave_device.is_listening=false zwave_device.is_routing=false zwave_device.is_secure=false zwave_device.manufacturer_info=[21076,1,34064] zwave_device.max_data_rate=null zwave_device.node_id=154 zwave_device.specific_class="Simple Remote Control" zwave_device.status=2 zwave_device.status_text="awake" zwave_device.version_info=[null,"1.1"] zwave_device.wakeup_interval=0Anything I could look at? Thanks.
Replacing SiteSensor Plugin (Vera) with MSR
-
@gwp1 said in Replacing SiteSensor Plugin (Vera) with MSR:
@toggledbits QQ on the OWM built-in: is there a means by which to render it inactive until I need to call it?
No. Controllers can only be switched on and off via configuration.
-
@gwp1I got this all working, Ambient's API and OWM's API all dumping to global expressions.
ambient_api
ambient_temp
ambient_windspeed
ambient_windgust
ambient_solarradiationopenwxmap_api
openwxmap_temp
openwxmap_windspeed
openwxmap_windgustEverything is glorious. I've planned for when the Ambient API drops (they were having big ol' issues today and into the evening now) it returns a NULL and I flip my HVAC control over to OWM API.
Except... Reactor gets very angry.
Now it's entirely possible this is on me - so let's review:
HVAC has three master rulesets, Cooling, Heating, and Neutral. You'll notice I've broken out the rules into Ambient vs OWM.The triggers for OWM include a "when Ambient returns NULL" clause, if you will.
These are my two "Site Sensors" in MSR:
This, too, works as intended with OWM sitting idle until Ambient goes "null" and then OWM starts making API calls and populating the global expressions with data.
In real world usage today/this evening the switch happens flawlessly. Where the angry Reactor comes in is after the switch happens. My confusion is around why any ruleset referencing the Ambient data (via global expressions) as a trigger suddenly has all the compile errors, throttling because update rates exceed 60/minute, etc. My expectation is that the "null" will blank the triggers in the ruleset and, since the ruleset is not triggered, it will go dormant until triggered again.
Where have I lost my way?
-
I don't recommend using
if
statements. There are coalescing operators to make the deferencing through the structures easier and tidier whennull
is a possibility. See the documentationAlso your API Sensor OpenWxMap would be better without the Interval condition and applying pulse output mode (condition options) on the null test.
As for the throttling, I would comb through all of your rules and reactions to see if you have any left-over Set Variable or other actions that would change the value of any of the subject variables. Something seems to be competing with what you've shown here.
-
@toggledbits I'm not understanding Pulse vs Interval. That trigger is intended to be how often it queries the API (yes, five minutes is aggressive - I'll pull that back once this is all working.)
There's nothing writing to those variables as they never existed prior to just a day or two ago when I reopened this project of migrating off of Vera's Site Sensors.
Now, there are a slew of rulesets READING from those. That's where my confusion lies, also. In my mind, if it reads the data and it doesn't match the trigger criteria it should just stop until the data changes again, no?
For instance, the Fountain ruleset is complaining. But it's only set to read from Ambient API values - it should be done until there's Ambient data.
-
It's just an alternate way of doing things. I'm not a fan of Interval conditions, and view them as a necessary evil, so I try to remove their use whenever alternate functionality accomplishes the same.
The big problem you have here overall is that, currently, global variables changing does not drive rule evaluations. I think this came up in the other thread. Just because your Ambient fetch rule is updating
ambient_api
does not mean thatambient_temp
is being updated in that same instant (that depends on how you are setting it, which you haven't shown us), and just becauseambient_temp
changes (no matter how you set it) doesn't mean that "Fountain via Ambient API" suddenly wakes up and checks it. This may simply be a current limitation of global variables as implemented that needs to be reviewed.Another issue I see here is simply one of structure. If you've got "Fountain via Ambient" and "Fountain via OpenWxMap", then I assert you're making your life harder. It would be better to have a
current_temp
rule that itself decides if it is going to use Ambient or OpenWxMap, and the "Fountain" rule (singular) has no idea where that data came from and doesn't care.current_temp = isnull( ambient_api?.whatever?[0] ) ? openwxapi?.whatever?[0].temperature : ambient_api.whatever[0].temperature
Also, even if everything operated to your assumptions, you have a race condition. There's an instant while the first OpenWxMap fetch is occurring that the query data from a previous query of hours, days, weeks, or months ago may be used, and that may cause reactions you don't intend until the OpenWxMap fetch succeeds and the data is updated. This is a side-effect of your goal of avoiding continuous OWM calls. There are workarounds, but the issue is moot at this point because the entire thing doesn't work like you think it does.
The implementation decision to not have global variables drive rule evaluation occurred early on. There were issues that prevented it, but since then, the rule evaluation algorithm has changed substantially. I'd need to study and test if this can be changed to work well under the new order. I agree it would be "better" (work more like expected) if rules could respond to global variable changes, but there are many opportunities for logic loops and other issues in doing that, so figuring that out and how to maintain control of the system and give the user meaningful feedback about such errors may not be a small task. (So I'm saying, I won't fix it today. Tomorrow's not looking good either.)
-
@toggledbits Firstly, there is no "Fountain via OWM" as it's missing one of the metrics I use to drive that stupid thing.
Secondly - yes, if global variables do not drive rule evaluations then this whole idea is moot. I was hoping to pull Site Sensors out of Vera at long last. It appears, at least taking the path I did, that this is not viable.
Regarding how I have
ambient_api
set:That populates the rest of the global expressions:
I need to think thru this some more if Global Expressions will not work as triggers. Has to be a way to present those datapoints as triggers like I've done with the Vera Site Sensors.
-
Give me a couple of days to see what I can noodle out on this. So far, things are looking like they're going the right direction, but sometimes you get >80% of the way before realizing you've painted yourself into a corner and need to take a different approach. Stay tuned!
-
Preaching to the choir. As you're well aware from my previous escapades, I do tend to make things much more complicated than they need to be. I don't want you compromising your product, though, just because I am going down the wrong path. Steer me back!
I would very much love to have shared elements like the outdoor temp, wind speed, and solar radiation something I can just point to. I've finally done that with HVAC, having only one master set and then pointing to them with the HVAC Ambient and HVAC OWN rulesets. Consolidation is king!
-
@toggledbits Better?
-
@tunnus I'm back knocking on this again. lol
I've enabled the OWM controller via
reactor.yaml
and this will be the dumbest question of the day, @toggledbits, but where do I see the results from it? Are new Entities created or should they appear underOWM Weather
?I know I'm gonna feel like an idiot at the answer but I can take it lol
-
Yeah, it creates new entities. In the Entities list, you can filter by controller. Do that. It should pop right out at you. If you want to get even more specific, filter on the
wx
capability, which is used by the entities that the controller publishes, and these are the entities you will want to use in rules. -
@toggledbits Hmmm... I'm.... not seeing the new entities at all.
Mental checklist/talking out loud:
- It's the same API/application key from SiteSensor in Vera and verified working.
- I went with the basic config, using default location.
- Restarted MSR via
Tools
- Key is not encased in single quotes
Refresh is set to 10: for now - does MSR do an automatic call on restart?
-
Did you enable the controller in its config?
-
Hang on lol. So it seems it creates the Entity as the location name, in my case "Charleston" and then the
wx
entities UNDER it. I should have picked that up from your screenshot with "PCT Current Weather" being the location.Only oddity.... this entry:
wx.location="Melgrove (historical)"
The rest of the data seems to line up just fine so that appears to be an outlier.
-
@gwp1 said in Replacing SiteSensor Plugin (Vera) with MSR:
wx.location="Melgrove (historical)"
The rest of the data seems to line up just fine so that appears to be an outlier.It's just what OWM returns for the location search given. Every location has official place names. Here in the US, the United States Postal Service has the official place names (for the most part), and we can end up with some "official" designations that have nothing to do with how the locals see it, sometimes decades-old and long disused (working at the speed of government, there). The installation instructions recommend using the official OpenWeatherMap city IDs for the greatest reliability in determining location, so you may want to look into that.
it creates the Entity as the location name, in my case "Charleston" and then the wx entities UNDER it.
Oh, and terminology here... the entity is given the place name (as set by the
name
field in your config, or if not set, other defaults), so Charleston here. Thewx
is a capability assigned to entity, not an entity under (or within) the Charleston entity. -
I will update the MSR config to be more specific vs using the lat/long from the base location. I believe that's how I did it in SiteSensor, actually.
Terminology is completely where I missed the data that was clearly present the entire time. Once again, a fine example of "ALL THE WORDS MATTER."
-
The final update here was that I decided against the onboard OWM config and went with creating matching Global Expressions generated via API call that I was using for Ambient's API. Consistency goes a long way for me. Paired up with matching HVAC rulesets that pull from the appropriate expressions and viola.
My biggest concern was around making useless calls to OWM's API (I try to be a responsible Netizen). I'd resolved that with SiteSensor by having the OWM version only arm itself when the Ambient one failed but, alas, that was not to be the path forward here. I bit the proverbial bullet and have the two running simultaneously and use
NULL
results from Ambient as my trigger for which rulesets actually action the HVAC. It's been working quite smoothly, knock on wood.I do see instances were Honeywell's API for the stats is just a bit finicky about setting both stats in a single call. To resolve this I've added some "course correction" rulesets that resend the correct setpoints after seven minutes. So far, so good.
-
-