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.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.
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.
Variables for fun and profit
-
Well the use of expressions in my Idiot Question over there has opened many new and exciting doors which I am itching to run through. This one has slammed in myu face
So in reactor we have an expression:
getstate( 46, "urn:upnp-org:serviceId:VClock1", "AlarmTime" )
which returns
Last result: "05:15:00"
Then we convert this to time one hour earlier:
time(AlarmTime) - 3600
which returns
Last result: 1658373300
Cool!
In MSR:
getstate is not supported
getEntity("vera>AlarmClock").attributes.x_vera_svc_upnp_org_VClock1.AlarmTime
Returns:
Last value: (string) "05:15:00"
Marvellous!
time (AlarmTime)
Returns
Last value: (null) null
Boo! Hiss!
OK seriously, is there a reference I've missed or somewhere I can look at this stuff. time() in Lua returns the epoch time which is fab, but what's my equivalent to the time usage in Reactor?
TIA
C -
Quick update, from reading the manual (doh)
time ([AlarmTime])
Returns an epoch time (yay) (or at least I think it does. See below
Unfortunately where in Reactor
time(AlarmTime)
returns the correct epoch time for my alarm clock
time ([AlarmTime])
in MSR returns epoch time that is equivalent to:Saturday, 1 January 2022 00:00:00
Which makes not a huge load of sense to me no matter which way I squint as it appears to be 7 months, 4 hours and 15 minutes out.
I throw myself on your mercy
C
-
@catmanv2 There might be better ways of doing it but this would result in an epoch time of current date and the time for AlarmTime.
do hms = split(getEntity("vera>AlarmClock").attributes.x_vera_svc_upnp_org_VClock1.AlarmTime, ':'), t = dateparts(time()), t.hour = hms[0], t.minute = hms[1], t.second = hms[2], time(t) done
-
No error at all, it just returns the 'wrong' epoch time. Behaving differently between Reactor and MSR (I would assume by design)
<edit> It appears part of this might be caused but Reactor time() conversion returning epoch time in seconds. MSR time() is (or appears to be) returning epoch time in milli seconds.The use case is as follow:
Set the alarm time (which varies, of course depending on weekends, holidays etc)
The alarm is triggered and turns on the Volumio player in the bedroom, gently increases the volume and wakes us up (ha!)Subtract one hour from the alarm time, and that's when we want the heating to come on from its overnight low.
Of course I could set the alarm one hour earlier, use that to turn on the heating then wait an hour to trigger the Volumio, but that feels inelegant as well as prone to bad choices of alarm time.
If anyone has a suggestion of how the first case might be accomplished, it would be lovely.
Cheers
C
-
Do you need to set the heating in epoch time?
If so and Reactor for Vera is in seconds you could just convert from milliseconds withsubstr(time(t), 0, 10)
and substract 1 hour by changing to this line instead
t.hour = hms[0] - 1,
in the above example.
-
@crille Really appreciated
No I don't need to set the heating time, there's a rule that compares current time to the calculated time for heating on. Given that
time(0)
returns epoch, that seemed a sensible way of doing itUnfortunately truncating the epoch in ms simply knocks the milliseconds off so instead of getting Saturday, 1 January 2022 00:00:00.000 you get Saturday, 1 January 2022 00:00:00
It should be
Thursday, 21 July 2022 03:15:00
or
Thursday, 21 July 2022 03:15:00.000Even using strftime returns Jan 1
Very very odd. Really appreciate your continued efforts though!
C
-
I'm a little lost and don't know what you actually want to achieve and what arguments you are giving
time()
.
We might get different results astime()
operates in the timezone set for the runtime.
I'll leave you with my tests and take a fresh look in the morning as it's getting late here. (sorry for Swedish in the screenshot asstrftime()
is locale-aware.) -
Ahh this appears to work, thanks so much!
I need to do some more testing, specifically around the testing of AlarmTimeSub1 vs current time but I very much appreciate your patience guiding this muppet!
<edit> So yes AlarmTimeSub1 evaluates perfectly. Now I need to compare that to actual time (if the actual time is later than AlarmTimeSub1, then I want the evaluation to be 'true')
time() >= AlarmSubTime1
Returns false.
C
-
FYI, @Crille has provided a correct example for computing an offset time to get an epoch (numeric) time to use for comparisons. The string comparison performed by
strftime("%T", time()) >= AlarmSubTime1
is really poor programming style and should not be used; numeric comparisons are better here. Unfortunately, the responses don't give adequate detail as to what "wrong" answer is produced by @Crille 's solution, so I can't comment other than the critique. -
Thanks. I have no programming style so happy to be educated
<types long reply to explain the 'issue'>
<while typing resolves the issue>
<deletes explanation>is
time() >= HeatTime
better style?<edit>
I guess I'm still curious as to why
time([AlarmTime])
in MSR andtime(AlarmTime)
in reactor return a different stamp (apart from the ms vs s part that is)Thanks again for all you do
C
-
@catmanv2 said in Variables for fun and profit:
is time() >= HeatTime better style?
Yes.
I guess I'm still curious as to why
time([AlarmTime]) in MSR and time(AlarmTime) in reactor return a different stamp (apart from the ms vs s part that is)You haven't given any examples of this. I don't believe it to be true (except, as noted, for millisecond precision in Multi-Hub Reactor). My guess is you are not actually asking about the return values, but about why the functions take different arguments. The reason is that the expression language in Multi-Hub Reactor is entirely new, and while there is some overlap between them, I would argue that the newer form is vastly superior and corrects many errors (read: decisions I made that I later regretted) in the Lua-based form. Another reason is that Multi-Hub Reactor is not Lua-based, so I did not feel the need to be Lua-compatible, whereas Reactor for Vera, being a Lua plugin for a Lua system, is meant to capitalize on existing user experience with Lua on that now-defunct (Vera) platform.
Also, if
AlarmTime
contains the string12:34:56
, the usingtime([AlarmTime])
in either Multi-Hub or Vera Reactor would be passing incorrect arguments to the function. If you want to pass a string, you do so without[]
surrounding. If you include the[]
, you are creating an array containing a string, which is nonsensical (to the function -- it sees an error). The documentation (for Multi-Hub) states that the function takes an optional single string argument, or up to six optional numeric arguments (representing in order given (year, month, day, hour, minute, second), or an optionaldateparts
-form object. The[]
you see in the documentation is from an old-but-still-widely-used BNF form to indicate an optional argument, it is not meant to be literally included in your expression. So the following would be valid calls to time:time()
with no arguments (because all arguments are optional)time( "2022-07-22T08:53:23+02:00" )
-- an ISO 8601 date string with TZtime( 2022, 7, 22 )
-- produces midnight on 2022-Jul-22 in the host time zone (three optional arguments not given -- hour, minute, second)time( 2022, 7, 22, 8, 10, 0 )
-- produces 8:10am on 22-Jul-2022 in the host time zone- and the
dateparts()
form has already been given in examples above by @Crille
Note that the string passed must be in ISO 8601 form, so a simple "12:34:56" time alone would not be parsable and produce an invalid result.
-
@toggledbits OK I'll try to give an example (I'm sure / hopeful you can explain)
In my Reactor (and I'm pretty sure you set this up for me a couple of years back!) I have:
getstate( 46, "urn:upnp-org:serviceId:VClock1", "AlarmTime" )
Underneath is stated: Last result: "06:00:00"Then we have
time(AlarmTime) - 3600
Underneath: Last result: 1658462400In MSR we have:
getEntity( "vera>Alarm Clock" ).attributes.x_vera_svc_upnp_org_VClock1.AlarmTime
Underneath: Last value: (string) "06:00:00"If we then do
time(AlarmTime) - 3600000
the result printed is
Last value: (null) nulltime([AlarmTime]) - 3600000
Returns: Last value: (number) 1640995200000Please note I changed the HeatTime in reactor to HeatTimeMSR in MSR just to demonstrate the 'difference' in output.
Clearly I'm missing something fundamental and obvious!
Cheers
C
-
@catmanv2 said in Variables for fun and profit:
If we then do
time(AlarmTime) - 3600000 the result printed is
Last value: (null) nullThis is expected because
AlarmTime
contains only06:00:00
, which is not an ISO 8601-compatible string.time([AlarmTime]) - 3600000
Returns: Last value: (number) 1640995200000Also expected, as I said above, because the
[]
surroundingAlarmTime
convert it to an array, which is a form of object, sotime()
is thinking its adateparts()
-compatible object and using what's available from it (which in fact is nothing at all, i.e. the "it's nonsensical" reference in that comment) to compute the time. -
Many of the functions behave differently, and this is intentional. The functions of Multi-Hub Reactor are (in my view) an improved evolution of any same-named functions in Reactor for Vera. Reading the documentation is key to success.
I'm working right now (back at my desk, yay!) at expanding the parsing capabilities of
time()
to make your particular use case a bit easier. -
@toggledbits that's super. Thanks again for all your help!
C