-
-
-
Hello,
Having issues updating to latest version. Is there documentation on it anywhere? -
I thought I would test and migrate my OpenLuup installation from my current old i3 Ubuntu server to a new Raspberry Pi 4.
I have set up the new Pi with a fresh install of openLuup and it works as it should.
As I have understood it I should install all the plugins I have on my old installation and then restore a backup file from my old installation onto the new server. Is this correct or should I do some more steps before migrating? When I see that everything is working the plan is to swap the IP, but initially the new server will have another IP.
When I tried to test the resore procedure on the new server from a backup file of the new server I got an error and the restore script hangs.
After reboot OpenLuup is back.What I did was type:
./openLuup_reload backup/backup.openLuup-88800000-2021-04-12.lzap
in the Terminal from inside cmh-ludl ( I found this procedure in an old thread).When doing this I get the following error message:
rm: can not remove '/www/altui/altui*': The file of catalogue does not exist (free-hand translated from Swedish)@akbooer am I missing something here?
-
The last three mornings OpenLuup for some reason has been unavailable. In other words it has not been responding when trying to connect via AltUI or Console.
I have been trying to investigate a bit around what this could be but not got it pinned down.
I run OpenLuup with one Zway bridge and two Vera bridges. The Zway and Veras have all been available every time, so that should not be the problem.
When the problems started I had updated OpenLuup with Mqtt and added a few Mqtt devices. At the same time I also updated AltUI to the latest version. At the same time I also removed some devices from Room 101.
The Mqtt devices are normally reporting data as they should.In Lua startup I have added the following entries related to Mqtt:
luup.attr_set ("openLuup.MQTT.Port", 1883) luup.attr_set ("openLuup.MQTT.Username", "luup") luup.attr_set ("openLuup.MQTT.Password", "openluup") luup.attr_set ("openLuup.MQTT.PublishDeviceStatus", "0") -- ================================== Mqtt functions below: local json = require "openLuup.json" function MyMQTThandler (topic, message) local info = json.decode (message) local t = info.AM2301.Temperature local h = info.AM2301.Humidity luup.variable_set ("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", t, 216) luup.variable_set ("urn:micasaverde-com:serviceId:HumiditySensor1", "CurrentLevel", h, 228) end luup.register_handler ("MyMQTThandler", "mqtt:tele/tasmota_test/SENSOR") function TasmotaCO2Axel (topic, message) local info = json.decode (message) local t = info.BME280.Temperature local h = info.BME280.Humidity local p = info.BME280.Pressure local c = info.MHZ19B.CarbonDioxide luup.variable_set ("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", t, 229) -- set temp to device luup.variable_set ("urn:micasaverde-com:serviceId:HumiditySensor1", "CurrentLevel", h, 230) -- set humidity to device luup.variable_set ("urn:micasaverde-com:serviceId:GenericSensor1", "CurrentLevel", p, 232) -- set air pressure to device luup.variable_set ("urn:micasaverde-com:serviceId:GenericSensor1", "CurrentLevel", c, 231) -- set CO2 to device end luup.register_handler ("TasmotaCO2Axel", "mqtt:tele/TasmotaCO2Ax/SENSOR") function TasmotaCO2Anton (topic, message) local info = json.decode (message) local t = info.BME280.Temperature local h = info.BME280.Humidity local p = info.BME280.Pressure local c = info.MHZ19B.CarbonDioxide luup.variable_set ("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", t, 233) -- set temp to device luup.variable_set ("urn:micasaverde-com:serviceId:HumiditySensor1", "CurrentLevel", h, 234) -- set humidity to device luup.variable_set ("urn:micasaverde-com:serviceId:GenericSensor1", "CurrentLevel", p, 235) -- set air pressure to device luup.variable_set ("urn:micasaverde-com:serviceId:GenericSensor1", "CurrentLevel", c, 236) -- set CO2 to device end luup.register_handler ("TasmotaCO2Anton", "mqtt:tele/TasmotaCO2An/SENSOR") -- =======================================================================This morning it seems as if OpenLuup stopped working at 06:24, I kept MqttExporer up and running over night and it the data reporting had stopped at that time. (The image shows the last reported data and then it shows that it commences again after I restarted OpenLuup at 07:19.
20210318MqttExplorer.pngBefore restarting I grabbed all the log files, the last few entries in the log are:
2021-03-18 06:24:09.712 luup.variable_set:: 149.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: -10.6 now: -10.5 #hooks:0 2021-03-18 06:24:09.712 openLuup.server:: request completed (2 bytes, 1 chunks, 4 ms) tcp{client}: 0x55ca8d503438 2021-03-18 06:24:09.721 luup.variable_set:: 229.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 20.4 now: 20.4 #hooks:0 2021-03-18 06:24:09.721 luup.variable_set:: 230.urn:micasaverde-com:serviceId:HumiditySensor1.CurrentLevel was: 46.7 now: 46.7 #hooks:0 2021-03-18 06:24:09.721 luup.variable_set:: 232.urn:micasaverde-com:serviceId:GenericSensor1.CurrentLevel was: 1016.5 now: 1016.5 #hooks:0 2021-03-18 06:24:09.721 luup.variable_set:: 231.urn:micasaverde-com:serviceId:GenericSensor1.CurrentLevel was: 2010 now: 2020 #hooks:0 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8cb5cf68 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8c855e68 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8d2daa08 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8c7c3218 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8ca87948 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8d312d98 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8c7e95f8 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8c74a218 2021-03-18 06:24:09.754 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8bfefea8 2021-03-18 06:24:09.755 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55ca8c6ebce8 2021-03-18 06:24:09.756 openLuup.io.server:: MQTT:1883 connection closed tcp{client}: 0x55ca8c4dfe48 2021-03-18 06:24:09.756 openLuup.mqtt:: closed tcp{client}: 0x55ca8c4dfe48 2021-03-18 06:24:09.756 openLuup.mqtt:: TasmotaCO2Ax UNSUBSCRIBE from cmnd/TasmotaCO2Ax/# tcp{client}: 0x55ca8c4dfe48 2021-03-18 06:24:09.756 openLuup.mqtt:: TasmotaCO2Ax UNSUBSCRIBE from cmnd/tasmotas/# tcp{client}: 0x55ca8c4dfe48 2021-03-18 06:24:09.756 openLuup.mqtt:: TasmotaCO2Ax UNSUBSCRIBE from cmnd/TasmotaCO2Ax_fb/# tcp{client}: 0x55ca8c4dfe48 2021-03-18 06:24:09.756 openLuup.mqtt:: ERROR publishing application message for mqtt:cmnd/TasmotaCO2Ax/POWER : closedThe last rows are a bit strange to me, them seem to indicate that something goes wrong with the Mqtt for that device?
@akbooer I assume that it could be more of interest in the logs, I can of course email them if needed. Also let me know if any more information is missing.
-
Creating my own topic for newbie questions about openLuup and AltUi 🙂
Trying to create a scene with a timer to turn on device 1 at given time IF device 2 is Off.
Wrote Lua to return false if device 2 is On.
Log states "scene prevented from running by local scene Lua" but action is performed anyway, device 1 is turned On.
Suggestions? -
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 modificationWhat 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.
-
I found some really minor gui issues in AltUI and in the Console.
Once more it is not that much of a problem for me as I use them only for admin purposes. I thought I'd post them anyway so that they are known for future releases, depending on priorities of course. 🙂
The first is related to the rounding of humidity devices in AltUI. It seems as if these numbers are always rounded down:
AltUI:
cae85b7d-8f20-440a-9ca2-8d568b63f00c-bild.pngConsole:
8100685e-9389-4f5f-b1e7-96a25fbabe84-bild.pngThe second issue is that the value for generic sensors seems not to be visible in the Console:
AltUI:
7909f921-2a09-4687-9550-331640e32244-bild.png -
I got tired on waiting for a stable release of Vera FW so finally took the leap to installing openLuup.
Unfortunately I haven't even got a simple scene to work.
Trigger - If device 1 is turned on
Action - Delay 2 seconds and turn device 2 on.I see the call to turn device 1 on in log but nothing else related after that.
What am I doing wrong? -
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 installed a new dimmer a few days ago, a Sunrichter "knob smart dimmer" (SR-ZV2835RACS).
It included without problems into Z-way and shows up in AluUI and in the Console as usual.
However the dimmer value in AltUI/Console does not change when you adjust it manually on the dimmer. I have checked the variables and it seems as if AltUI displays LoadLevelTarget and when checking on the dimmer variables the LoadLevelTarget value is not updated in OpenLuup when the dim level is changed on the dimmer. In other words LoadLevelStatus and LoadLevelTarget differs and LoadLevelStatus shows the correct dim level set manually on the dimmer.
If you change the dim level in OpenLuup then both values are updated.
On/off state is however always updated.In Z-way the dim level is updated as it should, so it works there as it should from what I can see.
Running OpenLuup 20.12.19 and AltUI 2.53b.2552.
@akbooer any idea if this is something that can be fixed?
-
so, @rigpapa did it: https://github.com/toggledbits/Vera-Decouple
It's completely decoupling Vera from the cloud. Very cool stuff. /cc @rafale77 @akbooer
-
This is a set of openLuup icons to replace the ones which you normally would transfer over from the vera. The only thing for the dimmable lights is that one needs to use a new json file to replace the original light bulb with an vector graphics type which I am also sharing.
icons.zip
D_DimmableLight1.json.zipThis is a sample of the icons on ALTUI:
-
What's the effort/work to have a custom device "view" ?
Remember when I talked about a dimmer with low/med/high/off instead of the slider from 0 to 100 ...
What I would need to do to have that ?
Right now, I have a fan in the living room that use the fireplace heat to send it on the 2nd floor!
For the moment, I put it manually at 30%, 60% and 100% to handle the low/med/high, but will be more useful on the interface to have only 3 buttons...
-
Screen Shot 2021-02-23 at 07.14.43.png
@akbooer , I just noticed these last 3 watches which have a serviceID appended behind them in the console. It is only the last 3 and I can't figure out why. Any idea?
-
A brainfart or maybe wishful thinking here but besides MQTT, it would be a really nice addition for openLuup to provide a websocket server which would "lock" the messages tighter than MQTT and then give allow MSR to connect to it through this protocol rather than the vera style http API.
This came to me as I was observing MSR connection to openLuup through polling adding 0.3-0.4% of CPU load while not doing much of anything to Home-assistant. Just putting it out there. z-way-server also provides a websocket server through an app which could be used instead of the current fixed interval polling of the z-way bridge. MQTT would provide the same benefit but likely require a lot more user intervention to setup the MQTT topics and messages though it would lose the distributed clients/servers aspect. -
I am not sure if this is the behavior inherited from the vera but I was looking at the codes and got annoyed that the LastTrip variable updates even when the variable set is to "untrip" the sensor. A bit of a pet peeve but I ended changing this behavior in the openLuup code to only update the LastTrip when it is a trip action. This is particularly annoying because of timed lighting or other sensors which are sending API calls to openLuup on a regular interval defeating the purpose (at least the one I think it is meant to have) of the variable.
I just moved this line
set ("LastTrip", tostring(os.time()))down to the armedtripped part of the code in the luup.lua file.
@akbooer was there a reason for that behavior?
-
Have you ever considered running openLuup under LuaJIT instead of Lua5.1 interpreter?
The LuaJIT Project
For kicks, I switched my installation to the latest LuaJIT2.1 beta3 dating from 2017 and being a lua5.1 interpreter it is a drop in replacement. I had to move the lfs library from one folder to another likely because of an include path difference but I am seeing a further speed/efficiency improvement vs. lua5.1.
My CPU load has dropped another 25% to now hover around 2.2% down from 2.8%. I have yet to make sure that everything else works but so far everything appears to be the same.
The luajit site claims up to 5x speed increase through the interpreter and 120x improvement through the compiler vs the standard lua5.1.Screen Shot 2020-07-05 at 23.10.02.png
My initial interest was from being able to access some ffi libraries to handle video streams...
PS: Wow it is pretty impressive under load... browsing through ALTUI which used to cause spikes of CPU utilization from 2.8% to 4.8% now only go from 2.3% to 2.6%. It almost looks like noise. I am running it on a pretty fast x64 thread so it may not be that significant but this could make a big difference on ARM.
-
A little while back the contents of the App Store in openLuup show that there are no plugins in the store and the date is shown as"
Alt App Store (as of 1970-01-01 10:00:00)In the log I see this:
2021-02-07 11:34:06.509 openLuup.wsapi.cgi:: /console : loading app database... 2021-02-07 11:34:06.550 openLuup.client:: WGET error status: -1, request: https://raw.githubusercontent.com/akbooer/AltAppStore/data/J_AltAppStore.json 2021-02-07 11:34:06.550 openLuup.wsapi.cgi:: /console : JSON decode error @[5 of 107, line: 1] unexpected data after valid JSON string 'tlsv <<<HERE>>> 1 alert protocol vers' 2021-02-07 11:34:06.569 openLuup.server:: request completed (8645 bytes, 0 chunks, 61 ms) tcp{client}: 0x34e2f68In AltUI, the store shows OK but I don't see a call to GitHub so it may be getting its info from a cached value or an xml file?
-
I was toying with the idea to write a simple openLuup plug-in to execute any external plug-in (ie written in nodejs, puthon or even bash or .NET) via an openLuup plug-in, with access to luup's variables and/or the ability to execute actions against an external executable.
The general idea is to get an existing library (ie: the one controlling LG TV, or SwitchBot) that's written in another language and write a simple (and generic) bridge to represent a device, getting variables from a command line bash script (or nodejs app or whatever) and leverage someone else's work, instead of playing catch-up and try to port it over to LUA.
I did it by myself in my own fork of the MQTT2Luup bridge I released and it's working very well for me. I was able to implement support for Alexa, busylights, lgtv, netgear routers, switchbot and much more, all using established or official node packages, with a simple library to send command to the node lib (simulating a console in) and getting response from them (reading the console out). So my logic is still in the luup/openLuup engine and I could mix and match (ie: getting my TV volume to know if I want to raise up/down the thermostat temperature based on occupancy, or treat switchbots as normal light switch - and control them via Alexa and so on).
So, instead of doing it all by myself, I'm wondering it this could interesting as a generic openLuup capability, or as a general and "standardized" effort. I know it sounds like MultiSystem Reactor, but it's not, since the primary purpose is to be specific to openLuup devices and leave the logic to the user (this could be of course Reactor, the upcoming MSReactor or whatever you want). Am I the only one mixing things together and with such a need?
openLuup: Version Log
-
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 modificationWhat 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.
-
Development Branch: 2020 Release 5.1
- Startup log shows JSON module version information (thanks @a-lurker)
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 decodingIf 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.6
I_openLuupCamera1
mods:- add
username
attribute - add
password
attribute - add
URL
variable - add
DirectStreamingURL
variable - thanks @prophead
-
Development Branch: 2020 Release 5.10
- native image panel for openLuupCamera1 device
- category 6 for ditto
- file counts in Luup files page menu
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 5.20
- fix for cjson.null in decoded structures
- thanks @reneboer (and @mrFarmer !)
As usual, an earlier update breaks something. This probably wouldn't have been spotted for a while, since it doesn't impact VeraBridge or the ZWave bridge, but thanks to @reneboer's vigilance, it's found and fixed.
A little more detail. The Cjson module decodes Json
null
as the private data structurecjson.null
. The following code snippet shows the problem:local json = require "openLuup.json" local J = json.encode {1, nil, 3} local L = json.Lua.decode(J) local C = json.C.decode(J) print("JSON", J) print("Lua", pretty(L)) print("C", pretty(C))
writes the output:
JSON [1,null,3] Lua {1,nil,3} C {1,userdata: (nil),3}
However, the default openLuup
json.decode()
function has now been fixed, when it's using the Cjson module:local D = json.decode(J) print ("json.decode [using Cjson]", pretty(D))
now gives:
json.decode [using Cjson] {1,nil,3}
Kudos again to @reneboer and @mrFarmer !
-
Master Branch: 2020 Release 5.22
5th Aniiversary edition!!
Yes, it's five years since openLuup was unveiled to the world in this post:
...so I thought that today I'd roll up all the changes to date into the master branch.
I suppose I should also be setting out a roadmap. At the risk of it becoming a commitment, let's just say that, for the moment, it's just a list of incremental development ideas and some blue sky thinking:
- ZWay plugin integrated in openLuup distribution (as are AltAppStore and VeraBridge)
- native scene triggers – not the same as Vera, not the same as AltUI variable watches, but definable in the openLuup console.
- utilities for managing Data Historian archives
- better task & job messages
and then...
- fully asynchronous I/O
- enhanced HTTP server with data compression (perhaps using third-party web server?)
- Ajax calls for asynchronous updates of some console pages (Devices, Scenes, ...)
- ...
Ideas always welcomed!
-
Development Branch: 2020 Release 6.28
Implemented some recent suggestions to assist code/plugin development in the openLuup environment.
- the console
System > All Globals
page now starts with an entry for the shared environment (Startup / Shutdown / Test / Scenes...) - there is a link from the above item to the
Lua Globals
page within theLua Code
page group, which expands the content of non-standard (ie. user-created) global Lua tables in the shared environment. - a new system variable
luup.openLuup.cpu_table
contains the running total of CPU times (with sub-millisecond resolution) for all plugins.
The last item above may be used to profile run times for all the plugins:
local T = luup.openLuup.cpu_table -- yes, this is a table, not a function call print (T)
produces an output like:
(s.ms) [#] device name 0.010 [2] openLuup 0.650 [3] Alternate UI 0.010 [4] Alternate App Store 8.300 [13] Vera Edge 0.040 [16] BBB Sonos (Study) 2.690 [17] Vera 0 3.100 [18] Vera 1 1.470 [20] Netatmo 0.040 [42] DarkSky Weather 7.140 [48] Philips hue 4.140 [70] Studio hue
but it's also an object which you may use to calculate run-time deltas. Hence:
local T0 = luup.openLuup.cpu_table -- wait a bit local T1 = luup.openLuup.cpu_table print (T1 - T0)
will show you the elapsed CPU time for all the plugins.
(s.ms) [#] device name 0.000 [2] openLuup 0.020 [3] Alternate UI 0.000 [4] Alternate App Store 1.440 [13] Vera Edge 0.000 [16] BBB Sonos (Study) 0.080 [17] Vera 0 0.070 [18] Vera 1 0.560 [20] Netatmo 0.000 [42] DarkSky Weather 1.460 [48] Philips hue 0.770 [70] Studio hue
My thanks to @a-lurker for being a catalyst for these changes.
- the console
-
Development Branch: 2020 Release 6.29
Following yesterday's changes in v20.6.28, "wall-clock" time is now added to the system profiling instrumentation:
- new plugin device attribute
wall(s)
contains the running total of wall-clock time (with sub-millisecond resolution) - new system variable
luup.openLuup.wall_table
contains the wall-clock times (with sub-millisecond resolution) for all plugins - openLuup console
Scheduler > Plugins
page shows cpu and wall-clock times and their ratio.
The final item above should be a good indicator of when ( >> 1) a plugin is taking much more elapsed time than the CPU that it is actually using – diagnostic of blocking socket I/O or wanton use of
luup.sleep()
. - new plugin device attribute
-
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!
- added Required Files sub-page to the Plugins page group, showing which files/modules are
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
withRapidJSON
, and the like.Not fixed:
- the log file customisation in Lua Startup (sorry @CatmanV2, next time.)
- added Required Files sub-page to the Plugins page group, showing which files/modules are
-
Development Branch: 2020 Release 10.1
Thanks to today's influx of Shelly devices here, I've implemented a shorter data request for running scenes.
So instead of:
http://openLuupIP:3480/data_request?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=1
or even:
http://openLuupIP:3480/data_request?id=action&DeviceNum=2&serviceId=openLuup&action=RunScene&SceneNum=1
You can simply write:
http://openLuupIP:3480/data_request?id=run_scene&SceneNum=1
...much easier to program into all those new switched and relays!
-
Development Branch: 2020 Release 10.2
Shelly-itis has hit hard... here is the beginnings of a Shelly-like API for all openLuup devices:
Switches:
Turn on / off / toggle with:
http://openLuupIP:3480/relay/NNN?turn=on http://openLuupIP:3480/relay/NNN?turn=off http://openLuupIP:3480/relay/NNN?turn=toggle
where NNN is the device number.
Scenes:
Run scenes with:
http://openLuupIP:3480/scene/NNN
where NNN is the scene id.
This makes programming Shelly i3 switches for actioning any openLuup device particularly easy, and consistent with controlling Shelly devices from openLuup (or any HTTP command.)
-
Development Branch: 2020 Release 12.10
Fix long-standing error with retrieving icon files from Vera using VeraBridge
GetVeraFiles
action. -
Development Branch: 2021 Release 2.11
Two significant new developments available in BETA form:
- integral MQTT server (broker)
- integral Shelly device bridge
MQTT server
This server provides Quality of Service (QoS) 0: At most once delivery, only. That is (according to the specification): "The message is delivered according to the capabilities of the underlying network. No response is sent by the receiver and no retry is performed by the sender. The message arrives at the receiver either once or not at all."
IMHO, QoS 0 is perfectly adequate for almost any home automation application operating over an internal LAN. Messages are hugely unlikely to get lost somewhere.
From openLuup Lua Startup, Scene Lua, or plugins, you can directly publish and subscribe.
To publish:
local mqtt = luup.openLuup.mqtt mqtt.publish ("My/Topic/Name", "My Application message")
To subscribe, you use a standard Luup request handler:
function MyMQTThandler (topic, message) -- your handler code here end luup.register_handler ("MyMQTThandler", "mqtt:My/Topic/Name")
You can register any number of handlers to different topics, or a single handler to many topics. Currently only one wildcard topic is allowed, '#', which subscribes you to all user messages.
The MQTT server has to be enabled in Lua startup with the line:
luup.attr_set ("openLuup.MQTT.Port", 1883) -- choose any free port, you might not want to use this MQTT default
Shelly Bridge
The Shelly bridge is implemented in an entirely new way for openLuup bridges, requiring no configuration at all, and installing itself automatically when the first Shelly device announces itself via MQTT. Shelly devices get their configured name (or ID, if no name was set.)
The bridge functionality is in three parts:
- MQTT client – as described above, it creates announced devices and updates their variables. All published states are reflected in device variables. Some devices (eg. Shelly Swich v2.5) have specific child devices created for them too.
- ShellyBridge plugin – provides the standard Luup device interface, handling all the child device action calls.
- Shelly CGI interface for all openLuup devices – as described in release v20.10.2 above, providing a Shelly-like HTTP command structure for any compatible openLuup device to turn on/off/toggle and retrieve status, etc.
Currently only i3 and sw2.5 devices are supported.
Here's a screen shot of one of each of those on a test system. The i3 is represented as a scene controller. The sw2.5 has two BinarySwitch child devices:
Here are the variables in a sw2.5 parent device:
Here's the variables for one of the child switches:
This is all BETA, so very interested in reports (and logs) good, or bad.
-
Development Branch: 2021 Release 2.18
MQTT server now supports login credentials.
To set Username and Password for MQTT connections use the following commands in Lua Startup:
luup.attr_set ("openLuup.MQTT.Username", "---username---") luup.attr_set ("openLuup.MQTT.Password", "---password---")
-
Development Branch: 2021 Release 3.2
- MQTT server now supports all forms of the '#' wildcard (but not yet '+')
- ACE editor updated to 1.4.12
-
Development Branch: 2021 Release 3.5b
openLuup_IP:3480/relay/NNN?turn=...
allows device Id or name for NNNopenLuup_IP:3480/scene/NNN?
allows scene Id or name for NNN- openLuup console control panel for Shellies links to their native configuration pages
- MQTT disconnect error fixed
Examples of Shelly device control panels:
with scheduled timer pages:
-
Development Branch: 2021 Release 3.11b
This release includes a significant update for the monitoring and control of devices, and represents an intention to move away from the need for any UPnP Vera-style requests or polling.
Using the built-in MQTT QoS 0 server, two new sets of PUBLISH topics may be sent by openLuup:
- topics named openLuup/update/device_no/short_service_id/var_name (where short_service_id is the useful part of the serviceId – ie. the last alphanumeric bit.) These are sent as the named variable changes value (ie. not if it is set to the same value.) The message text is simply the new string content of the variable.
- a single topic named openLuup/status is sent every few seconds (user definable) cycling in a round-robin way through all of the devices. The JSON-formatted text message contains the current status of all the variables in that particular device. This, then, is the 'push' replacement for long-polling with a
/data_request?id=status
HTTP request.
In addition, existing functionality allows simple Shelly-style HTTP requests to control switches and lights. These will be extended to dimmers and other controls in due course. Since Release 2021 3.5b you can use the requests:
openLuup_IP:3480/relay/NNN?turn=[on/off/toggle]
allows device Id or name for NNNopenLuup_IP:3480/scene/NNN?
allows scene Id or name for NNN
The new MQTT published messages may be controlled by setting parameters in Startup Lua:
luup.attr_set ("openLuup.MQTT.Port", 1883) luup.attr_set ("openLuup.MQTT.PublishVariableUpdates", true) -- publish every variable update luup.attr_set ("openLuup.MQTT.PublishDeviceStatus", 2) -- publish a single device status every N seconds (0 = never)
The JSON format of a single device status report, which is very compact, is that of nested tables indexed by strings: device number / short ServiceId / variable name; such that flattening the table appropriately would give the MQTT topic used in openLuup/update messages (aside from that prefix.) For example, for openLuup (device #2):
{"2":{ "HaDevice1":{ "CommFailure":"0", "CommFailureTime":"0" }, "altui1":{ "DisplayLine1":"8Mb, 0.1%cpu, 0.1days", "DisplayLine2":"[Home]" }, "openLuup":{ "CpuLoad":"0.1", "HouseMode":"1", "Memory_Mb":"7.6", "StartTime":"2021-03-11T14:53:02", "Uptime_Days":"0.06", "Version":"v21.3.11", "Vnumber":"210311" } }}
With a round-robin interval of 2 seconds, a moderately-sized setup of 150 devices would be cycled through in five minutes, providing a sanity check that no transient device variable updates have been missed.
Additionally, the MQTT server now publishes some of the $SYS/broker/ statistics, as defined by Mosquitto
Also included in this release is the openLuup console dimmer control change suggested by @rafale77.
-
Development Branch: 2021 Release 3.17
The openLuup MQTT QoS 0 server now incorporates a UDP -> MQTT bridge (currently, uni-directional.)
This means that any machine which can send a UDP datagram (and, frankly, that should be everything) can publish to subscribers of the openLuup MQTT server without the need for any MQTT client library. The use of UDP means that there is very little overhead to sending the data, and that there is absolutely no possibility of blocking the host process. The UDP 'fire and forget' concept also meshes very well with the MQTT QoS 0 service level.
The UDP -> MQTT bridge is enabled at openLuup startup with the additional configuration parameter, which defines the listening port number:
luup.attr_set ("openLuup.MQTT.Bridge_UDP", 2883) -- UDP bridge PORT number
The UDP datagram format for publishing is:
TopicName/=/ApplicationMessage
By way of example, here's a tiny bit of Lua Startup code, which I've tested on a Vera:
local socket = require "socket" local sock = socket.udp() sock: setpeername("172.16.42.121", "2883"). -- send to openLuup IP and port local pk = (luup.attr_get "PK_AccessPoint") pk = "Vera-" .. pk: match "%d+" function test_watch (d,s,v,o,n) local msg = table.concat ({pk,'update',d,s,v,'=',n}, '/') sock: send (msg) end local services = { -- list any services you want to watch here "urn:micasaverde-com:serviceId:EnergyMetering1", "urn:upnp-org:serviceId:SwitchPower1", } for _,sid in ipairs(services) do luup.variable_watch ("test_watch", sid) end
This sets up a device variable watch for all variables in specific services in all devices. When one of those variables changes, a UDP datagram of the form:
Vera-PK_AccessPoint/update/dev_number/serviceId/var_name/=/value
is sent to the UDP -> MQTT bridge and converted into a PUBLISH. For example:
- topic:
Vera-35104005/update/203/urn:micasaverde-com:serviceId:EnergyMetering1/KWH
- message:
18900.9060
Here's an MQTT Explorer view of my test system:
The updates are effectively instantaneous, and if Vera was in my long-term future I might write a new VeraBridge plugin to take advantage of this. I doubt that will happen, but I have plenty of other basic devices which could benefit from this transport mechanism. I may take that approach for an updated ZWay bridge. Future developments might include a bi-directional bridge, so that clients can also receive commands over UDP.
- topic:
-
Development Branch: 2021 Release 3.25b
- yet more checks around socket.send()
- error log lines now highlighted in red (for @rafale77)
-