@toggledbits Since I have upgraded ZWaveJSController to 24293 from 24257 I am seeing entries related to registering action set_volume, but action is not defined by the capability 143 every time I restart Reactor.
The Siren seems to be doing what it is supposed to do. The volume levels are fine. Should I worry about it?
Reactor version 24302
ZWaveJSController version 24293
Z-Wave JS UI version 9.27.4
zwave-js version 14.3.4
18481340-4d9c-4d0c-8027-49adfa28f32a-image.png
e0e1c895-a830-48d5-8346-cbae551b441d-image.png
This has been working flawlessly each year incl this year until... Tonight... nada.
Is this due to the holiday being late this year ie because today is the 22nd, not after the 22nd?
I've managed to use MSR UI on iOS devices to some degree*, so that although UI elements (e.g. rule sets) are not visible in portrait mode, you've seen them in landscape. Now with recents builds (24302) this does not work anymore, elements (rule sets, entities) are not anymore visible in landscape mode.
Does anyone have similar experiences? Using iOS 18 and Safari/Chrome browser.
( *Drag & drop of rule conditions have never worked on a mobile)
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.0
Hi!
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
[Solved] Hubitat Hub Information Driver v3 and probe device
-
I have upgraded my Hubitat Hub Information Driver to v3 and after the latest MSR update latest-23028 MSR is working ok. The problem is when MSR probes the device it appears to affect the polling in the new Hub Information Device and its data does not update the data fields in Hubitat. If I remove the Hub Information Device from Maker API so MSR can't see it, The Hub information driver updates the data as expected in Hubitat. I added the device back into Maker API the same problem returns in Hubitat. I have tried to have MSR probe a different device by adding a different probe device and probe action in the reactor.yaml per the documentation but it appears then it still uses the Hub Information Device as the probe device instead of the one specified in the reactor.yaml. See Logs below. Is this the intended behavior to always use the Hub Information Driver if found and not use the device in the reactor.yaml file? Any recommendations on how to get MSR and the v3 of the driver to work correctly or can you see what I am doing wrong?
[latest-23028]2023-02-11T23:27:50.471Z <Controller:NOTICE> Controller HassController#hass is now online. [latest-23028]2023-02-11T23:27:50.471Z <Rule:INFO> Internet Check (rule-l44qss4f in Home) starting evaluation; because entity-changed System#reactor_system>system [latest-23028]2023-02-11T23:27:50.471Z <Rule:INFO> MSR Update Version Available (rule-labweim2 in Notify) starting evaluation; because entity-changed System#reactor_system>system [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> Internet Check (rule-l44qss4f in Home) trigger evaluation result is false (previously false) [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> Internet Check (rule-l44qss4f in Home) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> MSR Update Version Available (rule-labweim2 in Notify) trigger evaluation result is false (previously false) [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> MSR Update Version Available (rule-labweim2 in Notify) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> Internet Check (rule-l44qss4f in Home) evaluation complete [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> MSR Update Version Available (rule-labweim2 in Notify) evaluation complete [latest-23028]2023-02-11T23:27:50.673Z <HubitatController:INFO> HubitatController#hubitat Maker API responded with 91 devices [latest-23028]2023-02-11T23:27:50.766Z <HubitatController:INFO> HubitatController#hubitat found 'Hub Information Driver v3' device #"481"; using for probe/health checks. [latest-23028]2023-02-11T23:27:50.780Z <Controller:INFO> HubitatController#hubitat 0 dead entities older than 86400000s purged [latest-23028]2023-02-11T23:27:50.780Z <Rule:INFO> Roku Pause (rule-l3nlrzu9 in Home) starting evaluation; because entity-changed BinarySensor#hubitat>519 [latest-23028]2023-02-11T23:27:50.780Z <Rule:INFO> Stairs Light Low Light (rule-kulslls9 in Living Room) starting evaluation; because entity-changed BinarySensor#hubitat>519 [latest-23028]2023-02-11T23:27:50.780Z <Rule:INFO> Porch Motion Extended check (rule-l3kr45m8 in Porch) starting evaluation; because entity-changed BinarySensor#hubitat>519 [latest-23028]2023-02-11T23:27:50.780Z <Rule:INFO> Porch Light Manual On (rule-kmtxw155 in Porch) starting evaluation; because entity-changed BinarySensor#hubitat>519Snippet from the reactor.yaml:
# action_pace: 100 # warn_unresponsive: true # probe_device: hubitat>132 (not needed if Hub Information app installed) probe_device: hubitat>2 # probe_action: x_hubitat_Configuration.configure (not needed if Hub Information app installed) probe_action: x_hubitat_Configuration.configure # probe_action: x_hubitat_Refresh.refreshSynology Docker latest-23028
Hubitat v2.3.4.139
Hub Information Driver v3 -
I am not able to duplicate the behavior you describe (Hub Info stops polling). I suggest you check your polling interval in your Hub Information device configuration and make sure it's a sensible number (and specifically not 0). There also have been several bug fix releases of that driver; the current version is 3.0.14 and that's what you should be on.
The documentation describes the
probe_deviceconfig as an integer; that's not what you have shown. It should be the device number only. It doesn't need to know which controller because you are in configuration for a controller. The Hub Information driver, if present, is still the preferred device and will override. -
I am running the latest version of the driver: v3.0.14.
It appears to me when MSR probes the device or if you press configure in the driver, all the new scheduled poll times increase causing them never to run. I have my poll times set as follows: poll1: 9 mins, poll2: 119 mins, poll3: 241 mins, poll4: 12 hours.
Here is a screenshot showing the scheduled poll times to start:
After MSR polls the scheduled poll times:
Poll3 and poll2 are not running.
Here is what I'm polling in the driver.
I know this is not your driver but I'm encouraged if you are not seeing a problem. I must have something configured wrong. Would you mind checking your driver and see if your scheduled times increase also?
-
They do. I use much a much shorter interval (actually, the default 300). It behaves the same way just using a simple refresh action.
That's going to make Hub Information Driver v3 unusable for this purpose, and send me back to the drawing board on the detection and probe for quiet channel. I'll look into it, but it may be a few days before I have time. I'm on other projects.
In your post/screen shots, I don't see any evidence, however, that the polls are not running. If they are scheduled, they are running. It's just a change in the interval caused by the Configure or Refresh. From what I can see, every attribute is being updated when the probe occurs. I am not seeing that the updates stop. So that just means things are being updated probably more frequently than you've scheduled -- pretty much opposite what you're reporting here. Are you seeing things that should be updated not be, or are you just assuming they haven't updated because of timing change?
-
It looks like when MSR probes the device, it then resets the next scheduled poll times to the time of the probe + whatever time you have set to poll in the device preferences. If you have small poll times then the polls might fire between MSR polls. Here is the filtered Hubitat log showing which polls run. lastPoll: baseData is when MSR does the probe. The first part of the log is with the poll:1 time is set at 9 minutes. If the time elapsed since a MSR probe > than 9 minutes then the poll:1 will run. It ran once at 06:45:15. I then changed the poll1 time from 9 mins to 3 mins at 8:00pm to test. You can see it ran more often but I don't know why the baseData slowed way down also.
dev:4812023-02-13 08:39:50.352 PMinfolastPoll : baseData dev:4812023-02-13 08:37:48.478 PMinfolastPoll : poll1 dev:4812023-02-13 08:34:48.349 PMinfolastPoll : poll1 dev:4812023-02-13 08:31:48.207 PMinfolastPoll : poll1 dev:4812023-02-13 08:28:48.062 PMinfolastPoll : poll1 dev:4812023-02-13 08:25:48.076 PMinfolastPoll : baseData dev:4812023-02-13 08:23:46.117 PMinfolastPoll : poll1 dev:4812023-02-13 08:20:45.974 PMinfolastPoll : poll1 dev:4812023-02-13 08:17:45.811 PMinfolastPoll : poll1 dev:4812023-02-13 08:14:45.676 PMinfolastPoll : poll1 dev:4812023-02-13 08:11:45.509 PMinfolastPoll : poll1 dev:4812023-02-13 08:08:45.408 PMinfolastPoll : poll1 dev:4812023-02-13 08:05:45.460 PMinfolastPoll : baseData dev:4812023-02-13 08:03:43.698 PMinfolastPoll : poll1 dev:4812023-02-13 08:00:43.644 PMinfolastPoll : baseData dev:4812023-02-13 07:56:18.977 PMinfolastPoll : baseData dev:4812023-02-13 07:54:17.207 PMinfolastPoll : baseData dev:4812023-02-13 07:50:52.589 PMinfolastPoll : baseData dev:4812023-02-13 07:44:17.322 PMinfolastPoll : baseData dev:4812023-02-13 07:39:17.057 PMinfolastPoll : baseData dev:4812023-02-13 07:36:18.474 PMinfolastPoll : baseData dev:4812023-02-13 07:34:16.720 PMinfolastPoll : baseData dev:4812023-02-13 07:26:27.444 PMinfolastPoll : baseData dev:4812023-02-13 07:24:16.188 PMinfolastPoll : baseData dev:4812023-02-13 07:21:27.225 PMinfolastPoll : baseData dev:4812023-02-13 07:14:58.542 PMinfolastPoll : baseData dev:4812023-02-13 07:09:15.465 PMinfolastPoll : baseData dev:4812023-02-13 07:04:15.275 PMinfolastPoll : baseData dev:4812023-02-13 07:01:16.758 PMinfolastPoll : baseData dev:4812023-02-13 06:59:14.981 PMinfolastPoll : baseData dev:4812023-02-13 06:54:14.847 PMinfolastPoll : baseData dev:4812023-02-13 06:45:15.886 PMinfolastPoll : poll1 dev:4812023-02-13 06:36:15.792 PMinfolastPoll : baseData dev:4812023-02-13 06:34:14.031 PMinfolastPoll : baseData dev:4812023-02-13 06:29:52.364 PMinfolastPoll : baseData dev:4812023-02-13 06:26:15.479 PMinfolastPoll : baseData dev:4812023-02-13 06:24:13.706 PMinfolastPoll : baseData dev:4812023-02-13 06:19:41.211 PMinfolastPoll : poll1I am not looking for an immediate fix or change, Just trying to communicate to you what I am seeing.
Would it be an option to write your own virtual device driver for Hubitat so you could probe that device and return the data you want for the health check?
-
That is all clear to me. What I am trying to convey to you is that the rescheduling of the polls does not mean that the Hub Information Driver v3 is not updating its attributes (in effect, doing the polls). When Reactor causes the probe (if it needs to), the driver does its poll at the time of the request, updates all of the attributes, and then reschedules for the next poll. So the attributes are still being updated, as I said, just sometimes earlier than the driver itself would do. I could leave it that way and most users would never know or care.
-
With all due respect and I do mean that and without beating this to death, I am only seeing the attributes that update when MSR probes are the baseData attributes witch per the Hub information driver’s documentation are (attributes: firmwareVersionString, hardwareID, id, latitude, localIP, localSrvPortTCP, locationId, locationName, longitude, name, temperatureScale, timeZone, type, uptime, zigbeeChannel, zigbeeEui, zigbeeId, zigbeeStatus, zipCode). I can find these attributes updating in the logs every time. Some examples of attributes that are not updating are publicIP and hubUpdateVersion among others. I use those attributes in rules and they do not update. I can not find evidence of these being updated in the logs or driver unless you set the poll time for these to very fast interval as I tried to document in the previous post. I do believe the next scheduled poll time is accurate and the attributes associated with the polls will not update until that time. Probably the best thing to do is to revert to the v2 driver.
-
Installation of Reactor build 23049 and configuring a virtual switch as a probe device appears to be working well.
FYI, The "Manual" link in the Reactor UI doesn't have the updated docs that are linked to in the Release notes thread. Hubitat Controller, Other Configuration, probe_device section. I have tried a hard reset in safari and Firefox browsers but the documentation is not the updated instructions. Thank You.
Synology Docker
latest-23049 -
Great. Thanks for letting me know.
-
T toggledbits locked this topic on
