-
"akbooer: Master Branch: 2021 Release 7.25
Long-overdue roll-up of the last year's development updates!"ak - congratulations on some great improvements coming to fruition. I can only hope you aren't running out of ideas! It's not easy.
I'd still like to see an "App Store" plugin download count but the invisible hands still need to be invoked by someone - whoever that may be!!
-
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.
-
Not sure which category to use, but it's about external access..
I'm using Dataplicity to connect from the web to openluup, and i'd like a similar connection for MSR. Thats not something i would use on a phone, but from a laptop situated elsewhere in the world (faulty logic always appears when i'm far away from home!)
I could offcourse do the same procedure (described in the lower part of this ) for MSR, but if I colud put a link somewhere in Openluup that would take me there (like the openluup console link?) that would be easier?
Don't know if it will work to connect to a different port?
Any ideas?
-
I'm setting up an openluup system (again) at my cabin, and this time i also added the dataplicity wormhole for external access..
I still use Imperihome to handle these on my phone, but ran into trouble when trying to add another "88800000" system, which seems to be the standard ID for openluup?
Any way to change the 88800000?
-
akbooer - sometimes when I'm looking at the graphs via the Data Historian in-memory Cache page; I hit the cache clear icon (circle with arrow head) instead of the graph icon (bar chart icon). Hence I have just destroyed what I wanted too look at. I just sometimes make some vague mental leap that the two icons are just one single "refresh chart" icon. Or perhaps it's just my big fat fingers.
However, I would like to suggest to make the icons further apart from each other and perhaps change the clear cache icon to a garbage icon. Sometimes known as a "trash" icon. Which I suppose it's a bit like a "freedom unit" 😉 .
-
Feedback / issues with openLuup's built-in MQTT server
-
I'm working on a very slow migration from DataYours to Historian and am wondering if there is a list of cache devices that can be modified to include some that are missing, specifically several voltage variable monitors in service EnergyMetering1.
Just checked again and a couple showed up. It could be that these populate slowly after a Vera reboot?
I would also like to modify the storage-aggergation, it is possible to edit that .conf file directly and reboot openLuup?
-
Hi AK,
I have my BlueIris NVR sending MQTT messages to openLuup for various triggers that occur in the NVR. Rather than configure start-up lua to subscribe to each and every BlueIris topic (there are many system topics as well as topics for each camera), I'd like instead to build an MQTT device specific to BlueIris, similar to the generic tasmota device type, to capture and display in variables, each topic and message sent from Blue Iris.
This way, I could then use Reactor to watch and act on message changes.
I've looked at the tasmota bridge code and believe I could re-purpose some of it to build such a device, but before I get into such an effort, is this something that can be done in an easier way? In general terms, I'm thinking of a an MQTT flag in the luup device creation that would specify an MQTT device and then the device would look for messages based on message filters established on a device configure page. Or perhaps a template of some sort that would act as a starting point for creating MQTT devices specific to an endpoint device.
-
I'm a fan of the SendConfig call action in a couple of scene...
Did you implement something like GetConfig ?
I have a couple of scene that I would need to do a GetConfig to do something based on the value...
-
I'm currently migrating everything from debian to the same VM using Ubuntu, 'cause z-way handle Ubuntu better than debian!
So here some question about openLuup 😉
1- Having some error on the console about GetNetworkState.sh (can't find file)
2- Is there a reason why openLuup can't handle lua5.3 instead of 5.1 ? -
Hi
I’ve been finding myself using the command line more with other applications and I’ve been enjoying the experience, learning basic shell/bash scripting etc.
What command line options are available with openluup?
-
@akbooer, have you thought about using rapidjson instead of cjson?
xpol/lua-rapidjson xpol/lua-rapidjsonA JSON module for Lua based on the very fast RapidJSON library. - xpol/lua-rapidjson
I am testing it on ALTUI and doesn't appear to be as strict as cjson while being even faster.
miloyip/nativejson-benchmark miloyip/nativejson-benchmarkC/C++ JSON parser/generator benchmark. Contribute to miloyip/nativejson-benchmark development by creating an account on GitHub.
Benchmarks comparing dkjson, cjson and rapidjson halfway down the page:
Performance compared to lua-cjson. · Issue #275 · Tencent/rapidjson Performance compared to lua-cjson. · Issue #275 · Tencent/rapidjsonI have write a json module for lua based on RapidJSON. The performance test result over lua-cjson is: On windows: My json module performance a bit slower than cjson when processing booleans nulls s...
performance/nulls.json: (x10000) module decoding encoding dkjson 1.5754740238 0.0276830196 cjson 0.0551309586 0.0487358570 rapidjson 0.0545330048 0.0497119427 performance/booleans.json: (x10000) module decoding encoding dkjson 1.4916000366 0.5738999844 cjson 0.0556819439 0.0495460033 rapidjson 0.0491378307 0.0377278328 performance/guids.json: (x10000) module decoding encoding dkjson 2.3570721149 3.0556299686 cjson 0.1626739502 0.1092689037 rapidjson 0.1135668755 0.0830221176 performance/paragraphs.json: (x10000) module decoding encoding dkjson 8.5023150444 31.5211300850 cjson 0.8555159569 0.6739630699 rapidjson 0.3181121349 0.1543619633 performance/floats.json: (x10000) module decoding encoding dkjson 2.1173479557 1.7756278515 cjson 0.1096220016 0.3009288311 rapidjson 0.0733149052 0.1116719246 performance/integers.json: (x10000) module decoding encoding dkjson 1.7672340870 1.3564231396 cjson 0.0811710358 0.2808339596 rapidjson 0.0581030846 0.0484278202 performance/mixed.json: (x10000) module decoding encoding dkjson 16.8118801117 13.2526481152 cjson 1.3187069893 0.7380268574 rapidjson 1.3779308796 0.4688320160Edit: I have implemented it across all of my plugins without the openLuup.json wrapper and have been running error free. Will let you know in a couple of days if I would recommend this but it is looking very good so far... It can completely and seemlessly replace dkjson.
installation instruction:
luarocks install rapidjson --server https://luarocks.org/devThen run a replace of dkjson and cjson to rapidjson in every lua file in the openluup and plugin lua file folder.
-
Very happy getting Alexa to control Openluup devices. I'm wondering if there's any way to get Openluup to control Alexa only devices (such as wifi enabled light bulbs?
TIA
C
-
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? -
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. 🙂
openLuup Hangs
-
This is a rare hang/crash of openLuup but I was able to reproduce it pretty consistently now:
I get close to house, and open homewave, it starts a poll to openLuup.
Before the poll completes, my phone drops from the VPN for one reason or another and causes openLuup to hang.
Most of the time, it is because the phone switches to wifi as I am at home. Sometimes, it is because the signal is weak and the VPN tunnel gets dropped.It order to alleviate this, I have to wait until I am on wifi before opening wifi when I get home.
@akbooer , Any way to fix this problem?
-
We’ve talked about this elsewhere before... usually related to a network problem or bridged Vera reload.
I’m pretty sure it’s somewhere in the LuaSocket library, which, TBH, doesn’t handle timeouts very well. I tried to code around this in several places, but must be missing something. Very hard to isolate the issue.
-
Indeed, I just wasn't quite sure before but I ran a couple of tests to reproduce today and it is pretty consistent. I am also confident that it is the only way openLuup has crashed for me...
It is when a json is being sent to a client asking for it but the file transfer never gets completed as the client gets disconnected. If I try to kill openLuup on linux under this situation it actually goes through a 90s timeout before killing the process.
Knowing what I know of openLuup, yeah I would think it is in the luasocket but I was wondering if there was a workaround possible. -
@rafale77 said in openLuup Hangs:
under this situation it actually goes through a 90s timeout
Now that's interesting. There is a default 90 seconds timeout on the HTTP server. It has to be greater than 60 seconds, because that is the interval in which a status request will respond in the event of no other state changes.
-
From the LuaSocket docs at http://w3.impa.br/~diego/software/luasocket/tcp.html
master:settimeout(value [, mode])
client:settimeout(value [, mode])
server:settimeout(value [, mode])
Changes the timeout values for the object. By default, all I/O operations are blocking. That is, any call to the methods send, receive, and accept will block indefinitely, until the operation completes. The settimeout method defines a limit on the amount of time the I/O methods can block. When a timeout is set and the specified amount of time has elapsed, the affected methods give up and fail with an error code.
The amount of time to wait is specified as the value parameter, in seconds. There are two timeout modes and both can be used together for fine tuning:
'b': block timeout. Specifies the upper limit on the amount of time LuaSocket can be blocked by the operating system while waiting for completion of any single I/O operation. This is the default mode;
't': total timeout. Specifies the upper limit on the amount of time LuaSocket can block a Lua script before returning from a call.The problem, if this is the solution to the problem, is that the HTTP module wrapper makes this level of control unreachable.
I had briefly looked at alternative HTTP / TCP implementation libraries, but honestly, Luasocket is so deeply embedded in Vera that this is hardly feasible.
-
I came to the same potential solution but was wondering if these timeouts could be set somewhere in the openLuup code. Not knowing which function is actually sending the user_data in response to the Homewave call, I did not know where to attempt inserting these timeouts... in the server.lua file maybe?
-
Sorry for reviving this @akbooer but I wanted to give a quick update on lua socket.
I realized that the library used by luarocks is very old (3.0 RC1 from 2013) and that the apt debian/ubuntu version is a little newer (March 2015). The library has since gone through 5 years of development and I just installed the latest github version using this command:luarocks install luasocket --server https://luarocks.org/devIt compiles the library from the current GitHub master. I am not sure it will help but so far it has not hurt. Will test further...
-
No need to apologise... this issue needs to be fixed!
-
Well first problem after updating the lua socket:
.
I had some lua code sending an url with spaces which I did not have to url encode. Now I have to. luckily it is pretty straightforward to do with "url.escape(content)":
On the other hand... somehow I feel that the response is a lot faster... I may be dreaming and will need to test this more but homewave seems to have no lag on polling. I don't remember seeing this before.
-
Well with the communication being seemingly faster, I am now having a hard time reproducing the problem. I will post back if I am able to but so far, no hanging occurring. Even ALTUI seems to be updating its data from openLuup faster.
-
Update: I can't seem to reproduce the problem anymore in spite of trying hard even in manners which would frequently create this problem before so I think the luasocket update is potentially a fix for these openluup lockups (really lua socket lockup to be accurate).
Edit: Nope... I really can't reproduce the lock up anymore. I tried at least 20x the same scenario which would cause a lockup every 3rd time: Opening Homewave on my iPhone and have it poll openLuup while the phone is in the middle of switching between VPN through LTE and wifi. Granted I don't know whether it is because the poll completes much faster or if it is that lua no longer locks up. This may really be fixed. Can anybody else who has run into this problem confirm?
-
@akbooer, I am now fairly positive that the updated luasocket fixes the lockups. Been running for two days with full intent to lock it up trying all kinds to interruptions and I haven't been able to get it to hang. Maybe it could be part of the installation recommendations?
-
Excellent!
Have you checked that async HTTP is, in particular, OK?
I ask, because it delves deep into the LuaSocket library, so it’s not unlikely that something changed.
Does the update instruction you gave above work on a RPi? I need to give this a go!
I’ll be pleased to confirm that it’s not due to any openLuup-specific code!
-
Yes it works very well with the async http calls as well as I have a lot of my code making use of it.
The update method works, it asks luarocks to pull from the dev repo and should build and install version "scm2". It should be platform agnostic. (the command actually rebuilds the library).
The only thing I had to do is the url encode for spaces which makes use of the http_async module for which I had to change the url input by encoding the space in the url(%20).
-
Hi AK, please let me know if you have a version that works with the new lua socket. I have an other websocket problem and would be nice to see if this helps.
Cheers Rene
-
There is no update needed to openLuup itself. You only need to update the luasocket library...
-
Did the update openLuup still works. Did not help for my websocket issue though. If openLuup starts it connects just fine, but if connection is lost and I close and reconnect no data is received. Need to dig some more.
-
Maybe explain what module you are using? I had a similar issue with one of my plugins and I ended up slightly modifying the io module in openLuup. Maybe try my branch on GitHub?
-
I'm using the websocket module rigpapa created (with some fixes) https://github.com/reneboer/LuWS/blob/master/luws.lua to talk to the new Ezlo ws API. This is part of the EzloBridge i am making based on your VeraBridge as we spoke about. Just put that on GitHub https://github.com/reneboer/EzloBridge.
It is working except when the websocket gets interrupted. Also needs some better error handling etc.
-
Maybe a problem with the web socket itself? What is the source of the interruption?
As I said above, I have been desperately trying to reproduce my old problem with interrupting either the io connection or an http request response which used to make openluup or rather luasocket hang and I have no longer able to do so with the updated luasocket version.