openLuup: Version Log
-
TESTING Branch: 2021 Release 4.30
A rare release to the testing branch to evaluate the effectiveness of RapidJSON as an enhancement to the openLuup.json module and a full replacement for the venerable dkjson module, per @rafale77's suggestion here:
https://smarthome.community/topic/151/rapidjson-instead-of-cjson-and-dkjson
If installed, RapidJSON will become the json encoder/decoder for any code requiring the openLuup.json module, using a default option table for encode of:
{empty_table_as_array = true, sort_keys=true, pretty=true}
This provides compatibilty with the formatting of the native openLuup json module (although, regrettably, with a few more white space elements.)
Additionally, any code requiring the dkjson module gets, instead, the raw RapidJSON module (with no encode defaults.) This provides a significant performance boost to many plugins, including AltUI, AltHue, etc...
I'm keen, of course, to know if this causes any detremental effects, or if, perhaps, there should be some default encode options for dkjson substitute.
-
Development Branch: 2021 Release 5.23
Significant changes and additions to the Data Historian:
- Variable graphing pages enables plotting of any of the archives or the in-memory cache
- Database editor to view variable values and commit changes to the database
- Support for multiple Graphite Carbon databases (complete replacement for DataYours)
- New console page to show rules for which variables are cached and/or archived
- Historian archive rules now independent (decoupled from old Whisper database .conf files)
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.)
-
Development Branch: 2021 Release 6.21
Summer Solstice Edition
- Support for Shelly H&T child devices and battery level
- Tasmota prefixes and topics configurable in Lua Startup
If you have existing Shelly H&T devices, you will need to delete them, and restart, in order for them to be recreated (automatically on next update.) The battery level is shown in the parent ShellyH&T device in the usual way.
For Tasmota devices, you can change the default prefixes and topics recognised by the Tasmota bridge in Lua Startup:
luup.attr_set ("openLuup.Tasmota.Prefix", "tele, tasmota/tele, stat") luup.attr_set ("openLuup.Tasmota.Topic", "SENSOR, STATE, RESULT, LWT")
The default values are as shown above.
––––––––––
As proof of the solstice, here's openLuup's DEC variable, showing that the solar declination has reached its maximum of nearly 23.5 degrees...
-
Master Branch: 2021 Release 7.25
Long-overdue roll-up of the last year's development updates!
including...
- MQTT QoS 0 server
- UDP -> MQTT bridge
- Shelly device support
- Tasmota device support
- Highlighting of errors on log pages
- Simplified Shelly-like HTTP commands for device control
- Automatic substitution of JSON module with RapidJson, if available
- Data Historian improvements including better archive data plotting
- Solar coordinates available (for shades / lighting / etc...)
As ever, enormous thanks to those who provide ideas and feedback, or even criticism!
AK
-
A akbooer referenced this topic on
-
Master Branch: 2022 Release 11.22
Long-overdue roll-up of the this year's development updates!
Including:
- extended Shelly device support (H&T)
- update ace editor to 1.12.5
- numerous internal updates
Thanks to any/all still using this!
openLuup is still at the heart of my HA system, providing management of Shelly devices, Hue devices (through the excellent ALTHUE plugin by @amg0), a platform for native plugins, automation, &tc.
With the recent demise of my last Vera, and failure of one of my remaining two Zwave power meter readers, I have now finally removed all Zwave devices from my HA ecosystem, so am not able to provide any direct support on any Zwave issues.
-
Master Branch: 2023 Release 1.6
- REQUIRED update for Netatmo plugin authorization to function correctly
- correct long-standing issue with some LuaSocket library versions when finding own IP address
- remove leading and/or trailing blanks from room names (thanks @a-lurker)
-
Development Branch: 2024 Release 2.8
- Add support for Shelly Plus H&T
- some internal restructuring for TCP servers
The Shelly Plus H&T device currently generates an error message in the log every time it disconnects:
openLuup.mqtt:: RECEIVE ERROR: (Fixed Header byte) closed tcp{client}: 0x564bc05a8a88
...but this doesn't affect the operation of the device or the system, and doesn't generally occur in the log very often, since, when battery powered, the device spends most of its time in sleep mode.
-
-
Development Branch: 2024 Release 3.20
Spring Equinox Edition *
- the built-in MQTT server has been refactored and now fully supports both '#' and '+' wildcards
- the Shelly Bridge has been updated to take advantage of this for Plus devices
- minor improvements to scheduler's memory usage
*Spring equinox as demonstrated by openLuup's solar.DEC variable moving through zero from negative to positive values at 3:06 this morning:
-