Hello,
I am currently running Home Assistant and Vera at the same time. I have installed a couple of ZEN32 5 button controllers but having issues getting the additional buttons to control my Vera devices. Am using the ZEN32 (Z-wave JS) blueprint which works well for devices on HASS. In developer tools I can use the Light:Toggle service and toggle my kitchen light through Vera. If I create the same action through the ZEN blueprint it doesn't work.
Anyone have any thoughts?
Roger
Feedback / solutions with openLuup's built-in Shelly bridge.
Just noticed that when trying to reorder some expressions, e.g. move the most recent one from the bottom of the list to the first, this new order didn't "stick".
At first yes, but when visiting some other menus (obviously saving before that) and then coming back, the moved item was in its original position (in the end of the list).
I currently have 29 global expressions (which may or may not have some relevance to this problem). Using build 21281 on linux.
Can log a PR with logs, if this seems hard to reproduce.
Just updated to latest 21294, ran usual update, It appears to start ok in console, but will not load in browser. The NODE_path looks correct but the console log show the below error.
log
NODE_PATH /data/data/com.termux/files/home/reactor: [latest-21294]2021-10-23T15:55:41.542Z <app:null> Reactor latest-21294-c13ea5d starting on v14.15.4 [latest-21294]2021-10-23T15:55:41.546Z <app:INFO> Process ID 14540; platform android/arm #1 SMP PREEMPT Wed Jan 16 09:21:08 CST 2019; locale en_US.UTF-8 [latest-21294]2021-10-23T15:55:41.547Z <app:INFO> Basedir /data/data/com.termux/files/home/reactor; data in /data/data/com.termux/files/home/reactor/storage [latest-21294]2021-10-23T15:55:41.548Z <app:INFO> NODE_PATH /data/data/com.termux/files/home/reactor: /data/data/com.termux/files/home/reactor/app.js:231 throw new Error(a0_0x4c6635(0xd9) + process[a0_0x4c6635(0xdb)][a0_0x4c6635(0x107)] + '\x20does\x20not\x20point\x20to\x20the\x20Reactor\x20install\x20directory'); ^ Error: Environment NODE_PATH=/data/data/com.termux/files/home/reactor: does not point to the Reactor install directory at Object.<anonymous> (/data/data/com.termux/files/home/reactor/app.js:231:15) at Module._compile (internal/modules/cjs/loader.js:1063:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10) at Module.load (internal/modules/cjs/loader.js:928:32) at Function.Module._load (internal/modules/cjs/loader.js:769:14) at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12) at internal/main/run_main_module.js:17:47 NODE_PATH /data/data/com.termux/files/home/reactor: [latest-21294]2021-10-23T15:55:41.796Z <app:null> Reactor latest-21294-c13ea5d starting on v14.15.4 [latest-21294]2021-10-23T15:55:41.800Z <app:INFO> Process ID 14547; platform android/arm #1 SMP PREEMPT Wed Jan 16 09:21:08 CST 2019; locale en_US.UTF-8 [latest-21294]2021-10-23T15:55:41.801Z <app:INFO> Basedir /data/data/com.termux/files/home/reactor; data in /data/data/com.termux/files/home/reactor/storage [latest-21294]2021-10-23T15:55:41.801Z <app:INFO> NODE_PATH /data/data/com.termux/files/home/reactor: /data/data/com.termux/files/home/reactor/app.js:231 throw new Error(a0_0x4c6635(0xd9) + process[a0_0x4c6635(0xdb)][a0_0x4c6635(0x107)] + '\x20does\x20not\x20point\x20to\x20the\x20Reactor\x20install\x20directory'); ^ ```===group ```java===
Hi @toggledbits and others,
Could you help me out with the following use case? I have a z-wave module that doesn't have scene functionality, but I want to trigger a double click action on the switch.
What is the easiest way to do this in reactor? I'm struggling with this and I think I'm thinking too complex at this point.
I have an odd issue which seems to be only for Fibaro wall plugs. They come in to Z-Way with two "electric meter" entrys, one "Power" meter and a couple of alarm entrys. In addition to the switch that is.
One of the "electric meters" is KWh and the other one is seemingly Watts, but it stays at 0/-1w. The "Power" meter shows the Watts used right now.
When these come into openluup, the wrong electric meter is selected for displaying the Watts, is there any way to manipulate which one openLuup uses? I see that the sub channel for power also is transferred, but it isn't in the data Veraflux is transmitting to my influxdb..
Haven't used the watts reading for anything before now, now i want to estimate when my dryer is done based on power usage. 🙂
I noticed this morning something that have seen in the past but forgotten about.
When I restart the OpenLuup server (in my case an Ubuntu PC) the Vera and Z-way bridges do not get in contact with the corresponding servers, i.e. are shown in red in AltUI. The solution for me is to make a "Relaod Luup engine" and then they are ok. I do not know if it is a general issue or only for my setup.
To be honest it is not much of a problem since OpenLuup is so stable. If and when you restart the server the hazzle of reloading is not that big. In fact I had forgotten about it since it was so long ago I had to restart anything...
The one use case I can think of is that the server gets restarted due to a power outage or something and if you are not at home the system does not fully recover without manual interaction. I my case I have the server on an UPS, but still a thought.
Is this a known issue and is it something that can be addressed somehow? As I said low priority, at least for me. 🙂
I'm using this (relatively) new option "Suppress alerts on HTTP errors", but for one reason or another MSR is still showing HTTP errors on Status page?
Screenshot 2021-10-20 at 21.20.25.png
Screenshot 2021-10-20 at 21.19.35.png
(tested with build 21297)
The drums are beating - what's the truth in the rumor?
A few new functions have worked their way into Reactor's expression language over the last couple of months, and while they are documented in the change logs and documentation, it seems some of you are not aware of them, so I'm going to pick one out and highlight it, maybe do others later...
A lot of you build strings in expressions by simple concatenation, and there's nothing wrong with that, but there's a new function in the expression language that can help you clean things up, in particular when handling numeric values.
I've noticed many of you will round your results either on the calculation, or in some cases, in a separate variable. For example, say we have a pair of expressions that retrieves the indoor and outdoor temperature from a sensor and the weather service:
indoor = getEntity( 'hubitat>144' ).attributes.temperature_sensor.value' ) outdoor = getEntity( 'weather>home' ).attributes.wx.temperatureThe weather service, since it converts from degrees K in its reporting to degrees C, may have an irrational or repeating value (e.g. 8.233333333...). As a result, when you compute the difference, it, too, may have an irrational or repeating result, so you decide to round it to one decimal:
tempDiff = round( outdoor - indoor, 1 )Then, perhaps you have a rule that if the differential is greater than 10 degrees, you send a notification, and the notification uses all three variables in the message string:
${{ 'The outdoor temperature is ' + outdoor + 'C and the indoor temperature is ' + indoor + 'C; the difference is ' + tempDiff + 'C' }}This is fine, except that the outdoor temperature isn't rounded, so you decide to fix that. There are at least three ways: add a round() to the outdoor variable expression, or create a third variable like outdoorRounded = round( outdoor, 1 ), or, use the round() function into the substitution expression
${{ 'The outdoor temperature is ' + round( outdoor, 1 ) + 'C and the indoor temperature is ' + indoor + 'C; the difference is ' + tempDiff + 'C' }}It's all getting very messy... Let's use format() instead of string concatenation, and not worry about rounding the difference, so we keep the maximum precision possible for any calcs or tests that use it. We go back to:
indoor = getEntity( 'hubitat>144' ).attributes.temperature_sensor.value' ) outdoor = getEntity( 'weather>home' ).attributes.wx.temperature tempDiff = outdoor - indoorNow our string substitution:
${{ format( "The outdoor temperature is {0:.1f}C and the indoor temperature is {1:.1f}C; the difference is {2:.1f}C", outdoor, indoor, tempDiff ) }}Here, format() is building the message string. Each {} (curly-brace) pair denotes the substitution of a parameter to follow. The number first inside the opening curly brace is the parameter number, starting from 0 as the first parameter. So parameter 0 in this example refers to the variable outdoor, and 1 is indoor, and 2 is tempDiff. Using the numbers, parameters can be inserted in any order.
Each of these substitutions in the example includes an optional format specification. If no format specification is given (e.g. {0}), then the parameter is converted to a string with no special formatting, but since we can get numbers like 8.233333... it's desirable to use some formatting to make it pretty. The format is separated from the parameter number by the : (colon) in the substitution. The format we're using for all three parameters is .1f, which is <width>.<precision>f. Any number before the dot is a fixed field width, but since we want no extra spaces, we just don't specify a width (it's blank for our example), and the value will take as much space as it needs. The f at the end tells format() that the value is going to be formatted as a floating point number, and the .1 before the f tells the formatter to display a single decimal digit. So our 8.23333333 value would be displayed as 8.2, without using extra functions or variables, or dropping precision in a calculation. For clarity, 10.875 would be displayed/inserted as 10.9 in this example, because the formatter will round the displayed result to the specified number of decimal digits.
Tip: for simple string insertions that require no special formatting, format() will let you skip the parameter numbers if the parameters are in the same order as the substitutions, and the default format is (generic) string (s), so format( "{} x {} = {}", "alpha", "beta", "gamma" ) produces the string alpha x beta = gamma.
Docs for format are in the Reactor documentation under the heading Special Reactor Functions.
@toggledbits Master, following the discussion of this thread, the variable FaultMSG is composed with the list of devices that will be displayed, example below.
07849e24-9a19-4957-a585-cfcd12088620-image.png
As you can see, the final string of devices, not sorted by name, follows the array generated by the device ID, composed one step earlier.
07fec184-0814-45e4-b689-533372af1fb4-image.png
Is it possible to sort by device name? Before generating the string? I think when generating the array?
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.Is there a way to back-up MSR Rule Sets and Configuration. I need to update my QNAP Container Station MSR install which I understand is not straight forward. If it all goes pear-shaped, and I loose my Rule Sets and Configuration, I wondered if it could be restored from a previous back-up?
Also, can someone possibly point me to the best method to update the MSR install on my QNAP?
Hello!
I want to trigger an event (like switching on a smart Zigbee power plug) when a regular light switch (that switches regular non-smart LED light bulbs) is flipped. Is there something I can put behind a light switch to achieve this? Or something to splice in between the switch and the light bulbs? A good option would also be Hue compatible.
Thank you!
Hi
I have some devices on my Vera Plus controller that sometimes change to say "Can't detect device".
I can clear those red banners that show up in the Vera UI7 web GUI, for a device by running some LUA code like this:
luup.set_failure(0, 331)Maybe I can use the new MSR matchEntities to find and detect any devices on Vera that have developed the "Can't detect device" error and then reset them. ?
I can currently manually specify a particular problem device in a ruleset trigger like this:
6f789006-ce19-4776-b3dd-290e28e84c8b-image.png
But if I could have a rule that automatically detects any device that develops this problem that would be better.
Thanks
@toggledbits I added an IP camera to my Ezlo for testing and my global variable for Ezlo devices that are not responding randomly do a quick toggle from empty to "IP camera" then back to empty.
Is it the controller interface not supporting IP cameras or something else causing this?
@2021-10-19T23:24:07.826Z
I am trying to display the primary attribute on this device like all my other Hubitat devices. The attribute is x_hubitat_extra_attributes.Status. This gives an error in the log. I can't see what I am doing wrong with this one. Do I need to to something different to display this?
Log:
Screen Shot 2021-10-16 at 10.11.12 AM.png
local_hubitat_devices.yaml:
Hi,
I feel a bit stupid with this issue since I know it is working and that it worked before.
I just can't seem to have a date range (between) going past dec 31 to work. In the interim, I manage to acheive what I want by using the "not between" equivalent.
I am using MSR on a raspberry Pi and I do have the latest development version (21286).
Here is a screen capture on which I have both the "between" and its equivalent "not Between" just so that you could see it.
I is probably something stupid and apologise in advance.
Thanks
In the background of other work, I've been putting together a build system for the OpenWrt version that Ezlo is using on the Plus. Job done. I can build pretty much any package, which may come in handy some day.
As a test of that, I thought, why not build nodejs... and you know where that leads, right?
It took some doing. There are a lot of dependencies, and the errors you get when the dependencies aren't met correctly can be cryptic and took quite a bit of research and experimentation to resolve... weeks, in fact, over a couple of hours here, a couple there.
But it's done and I now have Reactor running on an Ezlo Plus.
I'm not sure what the long term utility of this might be. Since the new Ezlo philosophy is to upgrade your system automatically on reboots, and so far the upgrades have wiped substantial parts of the file system in my experience, this could be a non-starter as a platform — you wouldn't want your automations to get blown off the machine every time Ezlo upgrades firmware (because you don't know when that's going to be, and Murphy says it will be while you are on vacation with no remote access). But, if there is some place it can be tucked away safely, or if, as probably should be demanded by the user community, updates become elective and user-driven, it actually makes a nice Pi-ish platform to run on.
On to the next skunkworks project...
Timestamps do not match the UI time or the system time:
[latest-21286]2021-10-16T03:10:43.922Z <Engine:INFO> Engine#1 master timer tick, local time "10/15/2021, 8:10:43 PM" (TZ offset -420 mins from UTC)I tried adding TZ to the docker container with "docker exec reactor apk add tzdata" but there was no change in log timestamps. I have the TZ in the compose file as:
environment: REACTOR_DATA_PREFIX: /var/reactor TZ: America/Los_AngelesThis does set the UI time correctly. The Reactor config is also set correctly:
location: city: "Los Angeles"
Well, this probably won't be the last time that someone from there joins us here, but, for the time being, I think it's time to move on.
We have a critical mass of really constructive contributors here, and we should certainly be doing what @toggledbits suggests:
"Make it so!"
Clearly deranged. All I ever wanted to do was support openLuup users, and point out that, under the new regime, that was best done here rather than there!
@pabla said in Vera account suspended for a 1000 years:
you just don't know what you could say that will get you banned.
...I just mentioned bicycle wheels!
Anyway, welcome. Glad you're here.
I now have an alpha version of openLuup using MQTT to send ALL device variable status updates in real time. This beats the heck out of almost any other approach in terms of latency.
It publishes to topics named openLuup/device_no/short_service_id/var_name (where short_service_name is the useful part of the serviceId – ie. the last alphanumeric bit.) Here's a screen shot of MQTT Explorer watching this test system which is linked to a Vera.
Under openLuup, you can use the native App Store page...
http://openLuupIP:3480/openLuup?page=app_store
...which, of course, shows only openLuup compatible plugins. It's also very responsive.
Hovering over the plugin icon shows the description, and there are links to the App Store JSON and GitHub repository if you're a developer wanting to browse those.
Liking @LibraSun ’s statistical analysis of the situation there!
Also amused at the publication of my PM, which, in fact, was obviously personalised, and you can easily work out who it was sent to because of the specific mention of HomeWave. I may have sent other similar ones, but they would most probably have been directed specifically at openLuup users.
@perh said in Generic support for external plug-ins in different languages:
MQTT server, is that the same as a broker?
@rafale77 said in Generic support for external plug-ins in different languages:
A server is not a broker.
To be sure 'server' is an overloaded term. However, within the scope of MQTT, a server is a broker. The OASIS MQTT specification (version 3.1.1, which is what I'm implementing) uses the term exclusively, and defines it (on lines 31-32) thus:
"A program or device that acts as an intermediary between Clients which publish Application Messages and Clients which have made Subscriptions."
I have, indeed, written a server, so you will not need Mosquitto, or any other server, installed anywhere, although, as @therealdb points out, you can have multiple servers (on different ports.)
Development Branch: 2021 Release 5.23
Significant changes and additions to the Data Historian:
In addition, the openLuup plugin device now has variables for solar Right Ascension (RA), Declination (DEC), Altitude (ALT), and Azimuth (AZ), which are updated every two minutes. Also a GetSolarCoords action which gives these values for any given time (defaults to now) and latitude/longitude (defaults to current location.) These calculations have always been done by openLuup to support scene times of sunrise/sunset, but are now available for use (negating the need for a separate plugin, eg. Heliotrope.)
Master Branch: 2021 Release 7.25
Long-overdue roll-up of the last year's development updates!
including...
As ever, enormous thanks to those who provide ideas and feedback, or even criticism!
AK
Not giving up on the idea of a bridge for openLuup
Currently I’m working on new concepts for plugin implementations, taking Shelly as an exemplar. If successful, this could be a framework for other protocols.
Unlike the other place, I’m looking for a seamless evolution of API and capability. The BIG IDEA is to implement ‘plugins’ as CGI files which could be run under almost any web server. A significant part of openLuup’s extended functionality is already implemented in this way (Historian, Console, ...) For a complete transition, I would need to wrap some existing parts (Luup requests, bridges, ...) as CGIs. This would, eventually allow me to lose the weakest part of openLuup, which is its own web server...
Just for you, I’ve bought one of my own. Hasn’t arrived yet, but I’ll be right on it when it does.
AK
OK, so we’ll have to do this in an iterative way, with me making a few mistakes.
This is going to be hard without having a dimmer. You're not in the UK, are you? I didn't really want to buy one (£22 UK price) because I have absolutely no need of one.
Any chance that anyone has got a spare one they can send me?
No, it’s not a problem that will be fixed by reinstalling.
I don’t understand your question
Yes, I don't believe that I've implemented the dimmer... I certainly haven't got one!
I'll take a look – thanks for the excellent configuration information!
Upon receiving a reload command, the openLuup engine exits its scheduler loop and then exits the program with a success code that causes the surrounding openLuup_reload script to loop and re-run the engine.
DataYour uses UDP to send data between its various components, so has absolutely no way of knowing whether a message is received or not.
Sounds like it's a network problem, and perhaps the LuaSocket library isn't coping well with that.
The ZWay plugin uses the high-level interface to the ZWay firmware. As such, it only has access to those things which that API provides. It seems somewhat random sometimes. Through this interface we are seeing the sensor in question, but it's an issue to do with how we represent these as child devices. However, the 'raw' variable in the parent device zway_71-0-49-4 is available for you to read, but you can't set a variable watch on it. You'd have to poll it with a timed scene, or such like.
I will look further into adding this to the child device, but, as mentioned, there may be a conflict with other reported power variables. We'll see.
Edit:
Yes, there is potential conflict. Just checked the source code and find this comment:
-- 2020.03.05 "Watts" conflicts with meter "50-2" if both present
I may, in general, be able to code around this in the event that there is no reported command class 50-2, but for this device there IS, so that's a problem.
Hmm, I see a bit of a conflict here. Command class 50 is for metering, but 49 is a multi-level sensor. It’s going to be hard to find a rule to deal with that automatically. Let me see if there’s a fix to achieve this manually… or, perhaps, @rafale77 has a suggestion?
Can you show me the complete variable list for the actual parent device? This should have all the values received from ZWay.
This is why I use push switches, rather than toggle switches… can’t bear to see a toggle in the ‘wrong’ position for the light status. That’s OCD for you! Same is true for two or three way arrangements.
I use the MK Grid switch hardware (in the UK) which allows you to swap out individual switches in a multi-switch wall plate.