Bit of an odd one this:
Bare metal install on Debian Bullseye (Intel NUC)

I've noticed when travelling, I connect to my L2TP VPN and I cannot get AltUI to update. I just get 'Waiting Initial Data'

Specifically this is in Chrome:
Version 108.0.5359.94 (Official Build) (x86_64)
In Chrome I can access and control everything via the Openluup console.
In Chrome I can also access and control everything via the Z-Wave expert UI and Z-Wave UI

In Safari I get a more complete view of AltUI but loads of errors along the lines of:
the module or function ALTUI_PluginDisplays.drawBinaryLight does not exist, check your configuration

Homewave on my iOS devices is fine across the same VPN config,
I can ssh into all my servers

Not a huge issue, just curious if anyone has any thoughts of what I might tweak to resolve it?

(FWIW I also access my IMAP and SMTP servers across the same VPN with no issues, as well as remote desktop. Also MS Reactor on the same host as Openluup)

TIA for any thoughts

C

I have Multi-System reactor set to with both my Vera Plus and Ezlo Plus - and up to a while ago, both were working. Recently, however, I noticed that it didn't seem to be communicating with my Ezlo Plus correctly. Looking at the logs, I see this:

[latest-22337]2022-12-09T03:44:49.980Z <EzloController:INFO> EzloController#ezlo: connecting to hub "90XXXXXX" [latest-22337]2022-12-09T03:44:49.980Z <EzloController:ERR> EzloController#ezlo: failed to get access credentials: [FetchError] network timeout at: https://vera-us-oem-autha11.mios.com/autha/auth/username/reactor?SHA1Password=<long_string>c&PK_Oem=1&TokenVersion=2 [-] [latest-22337]2022-12-09T03:44:49.980Z <EzloController:INFO> EzloController#ezlo will retry in 75000ms; this was attempt 17

So apparently it is getting a timeout when trying to connect to vera to authorize? How can I fix this, or does it simply not work any more?

Hass 2022.11.5 on Pi
MSR latest-22337-1a0a685f

This rule should be true now? I noticed that the first rule seems to reset either on HASS or MSR restart and not pick up where it left off, but thats not my current query now. The parts of the rule that look for freezing temperatures have set the rule, and constraints are met.... so why is it reset still? I just added the extra constraint for the lux battery power. But shouldn't the rule re-assess when saved?
I'm not sure this rule has ever set since I created it.
campervan.png

I'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:

GitHub - dbochicchio/reactor-mqtt-contrib: Contrib MQTT templates for Reactor GitHub - dbochicchio/reactor-mqtt-contrib: Contrib MQTT templates for Reactor

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 🙂

This is an old, well-established rule. It controls the ceiling fan in the LR. I don't want the fan running between the hours of 19:00 and 23:55 each evening so I have this condition:

66427999-2bf7-4deb-9f13-96806489750d-image.png

It's part of the larger:
397a1bf8-5c6b-4a4c-aee9-b7cfc2999ad0-image.png

If you look closely at the timebox rule you'll see it's set to not between and the time is definitely "between".

Is it me or is MSR ignoring the NOT in not between?

Currently I have a Vera and Hue hub all reliably controlled by openLuup with AltUI, plus any number of plugins. Been working really well for a few years now. However would like to head for a more MQTT based set up. Eliminate the Hue hub and hopefully eliminate Vera by using ZWAVE JS UI. Noting that Zwavejs2mqtt has been renamed to Z-Wave JS UI. Probably also run the stuff using Docker. Just because. Everything would end up on the one computer for easier management. Erhhh that's the hope.

Some of the new Zigbee Aqara stuff is very good and inexpensive plus it fits in with HomeKit. Also the Aqara battery powered stuff looks to have a good battery lifetime: ie suggested up to five years. The battery operated Hue buttons I have; have lasted for ages. Would like to use zigbee2mqtt with a SonOff dongle, which would allow access to the over two and half thousand devices zigbee2mqtt now supports:

| Zigbee2MQTT

AK has the MQTT stuff working in openLuup. Have played around with it and it works well, as one would expect. Love the UDP to MQTT code.

Shellys are great and also very inexpensive and they spit out & accept MQTT but I would prefer to stay away from WiFi. Not meshed and higher power consumption. Horses for courses.

Now here's the query:
Got about forty or more ZWave twin light switches, plus a few other ZWave bits & pieces such as blind controllers. Then there are the Hue devices on top of that. That's a lot of virtual devices to set up in openLuup. What's an appropriate way to do this?

It seems there is no "auto magic bridge set up". Do I need to use say @therealdb's Virtual Devices plugin that supports MQTT or is there some other approach?

I have to confess I still don't understand the master child approach in that plugin. Seems one light switch would have all the other light switches hanging off it? Helps Vera but not a problem with openLuup - why is that? Suspect AK's good coding beats Vera's?

dbochicchio/vera-VirtualDevices dbochicchio/vera-VirtualDevices

Virtual HTTP Devices plug-in for Vera and openLuup - dbochicchio/vera-VirtualDevices

Setting up manually say 100 virtual devices is a bit much to ask. I had a look at hacking the user_data.json file. Good approach till you see all the UIDs and the individually numbered ControlURL and EventURLs that need to be set up.

I need some way of say of creating about 80 light switches in "No room" or in say the "ZWave upgrade" room. Or say some sort of code that could go through all my existing bridged ZWAVE devices in openLuup and create virtual devices for each one. I caould then use the openLuup console to name them and place them in their rooms:

openLuup_IP_address:3480/console?page=devices_table

At that point I could hack the user_data.json file to insert the MQTT topics fairly easily for each? Plus any other fine tuning needed.

Then the old ZWave stuff could be swapped over to ZWAVE JS UI and all the virtual MQTT devices would be ready to go or am I dreaming? Then delete all the old Vera bridged stuff. I'm not too fussed about scene code and the like, as a I have all my code in one block, that is set up in the openLuup start up.

It seems that with ZWay you can create all the ZWave device by doing some sort of interrogation of ZWay's API? Seems also to be the case with the Shelleys?

So any ideas, suggestions or code snippets are welcome on how to move towards MQTT and in particular ZWAVE JS UI and zigbee2mqtt.

I'm in no hurry as openLuup is performing nicely, with the old Vera handling all my ZWave devices.

Hass: 2022.11.4
Hardware: Container
MSR: stable-22310-3006e85c

Hi,

I have a number of rules where the reactions change the brightness of lights....that have been working for months. I upgraded MSR recently however I don't think that is issue as I spun up the old container and the the issue remains.

This image illustrates the problem.

bfe42fd7-e038-4aba-bd5a-9892946f7d33-image.png

This what is now available in the dropdown menu

8ec17afc-c23c-413d-956a-fc992881b0e7-image.png

I can turn the light on/off from MSR and Hass however in Hass I can also control the dimming (saturation, colours, effects and so on).

It seems MSR is no longer 'seeing' a number of 'attribute'. At a loss as to what has changed.

Any suggestions most welcome.

Thanks

I use the excellent SiteSensor plugin of @toggledbits for some years to get the data from my PWS on Wunderground.
This has worked flawlessly but recently it suddenly stopped working.
I see this in my Vera:

6899a8b1-ad67-430a-9dc8-f1da42b04b62-image.png

When I copy/paste the URL code to be queried in my browser this still works.

This is the URL:
https://api.weather.com/v2/pws/observations/current?stationId=ILIMBURG130&format=json&units=m&numericPrecision=decimal&apiKey=xxxxxxxxxxxxxxxxxxxxxxxxx

Patrick (or someone else on this forum) can you help me solve this ?
Many thanks in advance!

With Raspberry Pi boards continuing to be relatively scarce, I've been trying a few alternatives to see what may be usable and good. I had previously written about the Jetson Nano 2GB, which is great, but a little pricey, so I'm trying to find sub-US$100 boards that will run Reactor.

I've got four that I'm trying now, but one in particular goes right to work in the most predictable way and seems worth a mention immediately: the Libre Computer Board AML-S905X-CC 2GB (known as "Le Potato").

The form factor is very similar to that of the Raspberry Pi 3 B+, and has comparable CPU (ARM Cortex-A53, quad 64-bit cores at 1.5+GHz -- slightly higher clock speed). It's US$35 on Amazon and LoverPi in the (recommended) 2GB configuration, and easy to get.

Startup is like RPi: download one of the available OS images (Ubuntu, Raspbian, Debian, ARMbian, etc.) from their site and write the image to a MicroSD card, insert into slot, power up, and off you go. I tried the Ubuntu 22.04 image first and it comes right up. No problem getting nodejs 18.12.1 installed and running (with Reactor).

No WiFi on board, but I don't see that as a minus for use as a controller/hub (which should be hard-wired, IMO). The 40-pin GPIO connector is compatible with typical RPi HATs (PoE, breakouts, etc.).

There is an available eMMC (solid state storage) module to use instead of MicroSD, which I would recommend for long-term use. It runs US$25 for 32GB (64GB and 128GB available). The module is scarcely larger than the chip it carries, and has the smallest board-to-board connector I've ever seen.

Next up: ESPRESSObin 2GB (spoiler: it's... technical...)

For comparison to other processors mentioned recently and in future:

Configuration: RPi 4B (maker board) 8GB RAM running Raspbian Bullseye

Raspberry Pi 4 Model B Rev 1.5 Cortex-A72 (aarch64) 4 cores @ 1800 MHz | 7.6 GiB RAM Number of Processes: 4 | Test Iterations: 1 | Test Duration: Medium -------------------------------------------------------------------------- CPU Mark: 619 Integer Math 11693 Million Operations/s Floating Point Math 4524 Million Operations/s Prime Numbers 3.1 Million Primes/s Sorting 3474 Thousand Strings/s Encryption 78.1 MB/s Compression 8676 KB/s CPU Single Threaded 479 Million Operations/s Physics 73.6 Frames/s Extended Instructions (NEON) 781 Million Matrices/s Memory Mark: 706 Database Operations 610 Thousand Operations/s Memory Read Cached 5942 MB/s Memory Read Uncached 3811 MB/s Memory Write 2900 MB/s Available RAM 6783 Megabytes Memory Latency 94 Nanoseconds Memory Threaded 3812 MB/s --------------------------------------------------------------------------

Configuration: Raspberry Pi 4 Compute Module Rev. 1.0 1GB RAM Raspbian Bullseye
Note the difference in clock speed between the Compute Module and maker board! 🤔

Raspberry Pi Compute Module 4 Rev 1.0 Cortex-A72 (aarch64) 4 cores @ 1500 MHz | 909 MiB RAM Number of Processes: 4 | Test Iterations: 1 | Test Duration: Medium -------------------------------------------------------------------------- CPU Mark: 520 Integer Math 9745 Million Operations/s Floating Point Math 3769 Million Operations/s Prime Numbers 3.2 Million Primes/s Sorting 3283 Thousand Strings/s Encryption 64.1 MB/s Compression 7155 KB/s CPU Single Threaded 402 Million Operations/s Physics 74.9 Frames/s Extended Instructions (NEON) 651 Million Matrices/s Memory Mark: 528 Database Operations 222 Thousand Operations/s Memory Read Cached 5269 MB/s Memory Read Uncached 4651 MB/s Memory Write 2911 MB/s Available RAM 794 Megabytes Memory Latency 97 Nanoseconds Memory Threaded 4659 MB/s --------------------------------------------------------------------------

The promise of "all available devices will be supported" gave me hope for including more Zigbee devices into to my home as Vera was not a good option for Zigbee devices.

Despite the support for new devices is extremely slow, the implementation of Zigbee has a lot to wish for and it seems a low priority at Ezlo I managed to include 22 of my 23 Zigbee devices as generic. But after 2 years of devices still missing attributes and randomly/every controller reboot loosing connection to the controller and had to be power cycled to connect again, and some even dropping off the network completely without any reason, I decided to give up.

The positive outcome of all this:
I bought a Sonoff Zigbee 3.0 USB Dongle Plus and installed Zigbee2MQTT and never been happier.
Suddenly the pairing were no pain and took a few seconds per device, all my devices were recognized, all capabilities of the devices were exposed and it never misses a signal to/from a device ever.

I'm surprised how stable and configurable my new setup is. I can set device parameters, offsets, send messages handled by the bulbs them self like effects, broadcast for groups, transition time for power on/off. I can handle debounce for MQTT messages, do OTA firmware update on devices and much more! Most of this is probably standard for the common branded hubs like Hue etc but I never had one so this is new to me.
A big plus for me is the MQTT part of Zigbee2MQTT as I'm migrating as much as possible to MQTT.

My Ezlo Plus is now serving as a modified WiFi access point to my network and only have the VistaCam 1203 Doorbell still connected for evaluation. Time will tell if I ever move my Z-wave devices to it.

Conclusion:
I could really recommend both the Sonoff 3.0 USB Dongle Plus and Zigbee2MQTT to anyone going the same path!

Re: openLuup: MQTT server

@ronluna

Hoping you could tell us a bit about your experiences with ZWaveJS and MQTT.

ZWave JS UI in MQTT Explorer.png

Hi

I’ve been investing a lot of time recently trying to digitise everything I can, and my current adventure is with all my paper documents.

My tool of choice is Paperless-ngx, which so far is an amazing open source solution, and highly recommended if you’re interest in such a thing…

Such a move to Paperless would not be complete without some form of integration into Vera / openLuup, and thankfully it has a nice Rest API (https://paperless-ngx.readthedocs.io/en/latest/api.html) I can use. So far I’ve been able to make use the GET requests, to provide document counts etc., but it’s the mutipart/form data piece where I’m struggling..

The Curl command to upload a document, is as follows

curl -H "Authorization: Basic Y2hyaXM62tgbsgjunotmeY2hyaXNob3N0aW5n" -F "title=Companies House File 10" -F "correspondent=12" -F "document=@/mnt/nas/10.pdf" http://192.168.102.134:8777/api/documents/post_document/

But, I’d like to know how to do this with Lua code, more just to help me in my Lua learning curve, and what I thought would be reasonably straight forward thing to do, has turned out to be quite the opposite 🙂 Sending a multipart form data submission via http.request, is not as straight forward as I hoped. If anyone has any time to help, I’d appreciate some guidance on what I’m missing with the following, as based on the feedback, it looks like it not seeing the file (which I think I’ve confirmed by trying to sending both the curl and Lua commands to httbin.org ) …

local http = require("socket.http") local ltn12 = require("ltn12") local mime = require("mime") local lfs = require("lfs") local username = "username" local password = "password" local httpendpoint = 'http://httpbin.org/post' local filepath = "/mnt/nas/10.pdf" local file = io.open(filepath, "rb") local contents = file:read( "*a" ) -- https://stackoverflow.com/questions/3508338/what-is-the-boundary-in-multipart-form-data local boundary = "-----BoundaryePkpFF7tjBAqx29L" local send = "--"..boundary.. "\r\nContent-Disposition: form-data; title='Companies House File'\r\n" .."----"..boundary.. "\r\nContent-Disposition: form-data; document="..filepath.. "\r\nContent-type: application/pdf".."\r\n" ..contents.."\r\n" .."------"..boundary.."--\r\n" -- Execute request (returns response body, response code, response header) local resp = {} local body, code, headers, status = http.request { url = httpendpoint, method = 'POST', headers = { ["Authorization"] = "Basic " .. (mime.b64(username ..":" .. password)), ["Content-Length"] = lfs.attributes(filepath, 'size'), ['Content-Type'] = "multipart/form-data; boundary="..boundary, }, -- source = ltn12.source.file( io.open(filepath,"rb") ), source = ltn12.source.file( io.open(send) ), sink = ltn12.sink.table(resp) } print(body, code, headers, status) print(table.concat(resp)) if headers then for k,v in pairs(headers) do print(k,v) end end

Solution: An update to openLuups MQTT implementation on handling acknowledge packets for QoS > 0 solved this issue.

EDIT: Seems related to any restart without any configuration changes. If I revert to 22310 I can restart Reactor from UI and with systemd within seconds, but with 22328 it fails to restart., both from UI and systemd. I have to stop the service and then start again.

I tested to comment out my http (not https) baseurl in the config on my bare metal Ubuntu install latest-22328 and triggered a restart from the UI but Reactor would not start after that.
If I uncomment the key and restart the service, Reactor comes back to life.
Is my setup an exceptional circumstance or is this only applicable on new installs?

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.

I've noticed lately (at least with build 22328) that in some cases these yellow warning / alert icons in front of rules are missing, although errors are otherwise visible:

Screenshot 2022-11-29 at 22.33.16.png

Screenshot 2022-11-29 at 22.31.15.png

A long while ago (May, 2015) I wrote my 2000-th post on another forum: openLuup - running unmodified plugins on any machine. Here’s the gist of it:

...I want to work in a more open and stable [Vera] environment...

...All would be solved if Luup was open source and could be run on the plethora of cheap and reliable hardware available today. But it’s not. But we could get something like that effect if we engineered a sufficient subset of Luup to run on such a platform. Could it be done? What would we need?

1. UI
2. scheduler
3. web server
4. Luup compatible API
5. Device and Implementation xml file reader
6. Zwave bridge to Vera
7. runs most plugins without modification

What we wouldn’t need is UPnP.

What have we (nearly) got already?

We have, courtesy of @amg0, the most excellent AltUI: Alternate UI to UI7, and that, I think, is probably the hardest one to do in the above list. Items 2 - 5, and 7, I’ve prototyped, in pure Lua, and posted elsewhere: DataYours on Raspberry Pi, running selected plugins unmodified, including: DataYours, EventWatcher, Netatmo, RBLuaTest, altUI. See screenshot attached.

Is it worth the effort? Probably not. Will I pursue this quest? Yes.

openLuup was the result.

DE2056BF-E548-4611-972B-40276F00BFEB.jpeg

Possibly stupid question. I have Owntracks on my phone. It's claiming to report to my Mosquitto server. However, when I transitioned out of the logged area today, I can't find any log entry that seems to correlate.

Is there documentation to integrate Mosquitto with AltUI or MSR? Or am I going the wronggggggg way (again)?

TIA

C

I was just going to add my support for a Update Button for the bare bones version of MSR and find the thread has been removed.
I'm wondering what was so provocative that required it's removal?
Have we become as paranoid as an owner of another forum?

Anyway +1 for an Update Button.

Hello @toggledbits I have a strange issue with the HTTP request that i send to Reactor.
I have two reactors one on a Unraid server and one on Ubuntu server installed as a docker, when i send http get request to the Unraid server to control home assistant entity everything is going ok, but when i send the same request to the ubuntu modified accordingly it says "Request failed" but when i try to run reaction via http request it works.

When i go to entities and try to control the entity manually its working.

Any idea's?

Best regards