A
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.
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 so happy with Starlink, myself, as I am an astro-photographer...
The company’s attempts to dim the spacecraft in its megaconstellation fall short of eliminating disruptions to the world’s ground-based observatories
Although we live in a rural area, we have fibre optic to the house with 1 Gb, since the CEO of a company who installs fibres lives in the village!
Just bought a Shelly Button 1. These things are tiny, and absolutely beautiful. Trying this out as a remote switch stuck to the wall in a place where I simply can't get any power line and use a regular Shelly ix3.
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...
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.
A list of openLuup releases including the latest developments…
A long while ago (May, 2015) I wrote my 2000-th post on another forum: openLuup - running unmodified plugins on any machine.
Now rehosted at https://community.ezlo.com/t/openluup-running-unmodified-plugins-on-any-machine/187412
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?
Is it worth the effort? Probably not. Will I pursue this quest? Yes.
openLuup was the result.
My Homepod mini arrived today. Very slick setup using an iPad. Happily discovered the Homebridge running in my Synology Docker, and all the configured devices (including my new Shelly Button 1!)
The revelation here is that the Homepod solves the remote access issue for openLuup, in that all the devices exposed (via MQTT) to the Homebridge are fully functional.
Love it! Thanks for the initial recommendation @rafale77 .
Finally, I’ve found an adequate replacement for my beloved MiniMote four-button remotes (I’ve had nine of them for the last 10 years or so!). I should have realised this earlier, but with four buttons and approximately the same form factor, the Philips Hue remotes are viable replacements…
…however, they are, of course, Zigbee and not Zwave, but this doesn’t matter in my HA environment, which has now completely ditched Zwave and Vera for all lighting and control functions, and replaced them with Hue and Shelly devices. These are all brought together with a Homebridge installation running under Docker on Synology NAS with the Apple Home app as the UI. This gives, of course, both secure remote access and voice control.
The MiniMote buttons I had configured as scene triggers to do whatever I needed, most usually toggling lights. The same functionality is easily achieved within the Home app by appropriate shortcuts.
I’m still using openLuup as a secondary hub which mimics all the various devices using MQTT and the ALTHUE plug-in and logs all device and sensor data using the built-in Historian and viewed through Grafana.
Works for me!
AK
Development Branch: 2020 Release 5.1
If you have installed Cjson then the startup log should include:
2020-05-01 13:00:56.780 openLuup.json:: version 2020.04.16 @akbooer
2020-05-01 13:00:56.780 openLuup.init:: using Cjson 2.1.0 for fast decoding
If not, then:
2020-05-01 12:54:47.675 openLuup.json:: version 2020.04.16 @akbooer
2020-05-01 12:54:47.675 openLuup.init:: Cjson not installed - using openLuup.json.Lua.decode() instead
Development Branch: 2020 Release 5.10
The openLuup console Luup Files page offers a very fast way to browse and view all the Luup device files that the system knows about. A click on the file name opens a Viewer on the file itself. The file filter menu now shows a count of each file type. I seem to have a total of 772 such files on my development system...
Development Branch: 2020 Release 7.4
INDEPENDENCE DAY Edition
...nothing to do with the USA, but the day in the UK when Covid-19 restrictions are reduced, and more shops and businesses can open!
required by plugins (and how many times.)This is in preparation for being able to specify replacement modules without altering the plugin code itself. Applications include replacing dkjson with RapidJSON, and the like.
Not fixed:
