-
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.
-
Feedback / issues with openLuup's built-in MQTT server
-
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?
-
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 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?
-
Hey guys...
in my openLuup startup I have
Tools = require "L_MyLuaCode"
And this, will read the file L_MyLuaCode.lua
Is there a way except to restart openLuup to re-read this file ?
-
Hello - the new pi has arrived with uzb. As an installation shortcut is there a way of 'factory resetting' openluup if I cloned the working image on my other pi ... or is that a really bad idea?
-
Do you think it could be possible to have a custom device for "dimmer" that instead of having the slider from 0 to 99 will give us Off/Low/Medium/High and will send 0,30,60,90 ?
-
I was trying to change the ID of a couple of scenes and came to the conclusion you can't do this without stopping openLuup, hacking user_data.json and restarting openLuup, which is a pain. (May be this could be added to openLuup ie be able change any scene ID to a non used one.)
So I figured I would try and clone some of the scenes with the idea that I could then manually swap their contents around. Why would I want to do this? Just to make my scene management a bit more simple as all my scenes call the one pile of Lua code. I also wanted to make use of unused scene IDs sprinkled through the scene ID list.
My understanding was the clone would occupy the first unused scene ID. Using AltUI, it just adds the clone on to the end of the list of scene IDs. In openLuup using the console page it failed to create the clone. Hits the URL OK:
http://openLuup:3480/console?action=clone&scene=14Says this in the log:
GET /console?action=clone&scene=14 HTTP/1.1 tcp{client}: 0x2c05008Searched high and low and no clones to be found.
I see that AltUI does a create when it clones:
openLuup.server:: GET /data_request?id=scene&action=create&json=WITH_ALL_THE_SCENE_INFO_HEREAny ideas?
-
I woke up to one of the lights in the hallway dimming up and down constantly.. when i tried to open reactor logic summary, there was something weird with the GUI?
The "Tools" tab resizes so i can't reach the logic summary button:
24f6b3f7-cfca-45ba-b568-7c6f5a31ddd7-image.pngThe Reactor instance in Altui pages was also empty, no buttons or text on them, only the icon..
I have a virtual switch to turn on all lights using reactor, and that one worked from the tablet in the kitchen, so reactor was functioning OK..
I reloaded luup and hard refreshed the browser, and all but the "Tools" page is now back to normal.. @toggledbits ?
EDIT: Theres supposed to be some text in the headers on this page, isn't it?
70159d9d-85fc-4606-b38b-49f2909dce72-image.png -
Windows Subsystem for Linux (WSL) is a compatibility layer for running Linux binary executables natively on Windows 10.
This is one way to run openLuup under Windows without having to worry whether any of your plugins require a Unix/Linux environment – this way, they actually get one.
Many flavours of Linux are available for WSL from the Microsoft Store – my favourite, to date, is Alpine WSL, which is a tiny (~8 Mb) and lightweight WSL distro based on musl, uses busybox, and just contains the most important things to be functional.
Here's a rough guide to getting openLuup going under Alpine WSL
Enable WSL on via the Windows control panel Install the Alpine WSL app from the Microsoft Store Start the Alpine application Install Lua and some libraries:Alpine comes with a really full set of Lua libraries available for install. You need to be su to install them:
# apk add curl # apk add lua5.1 # apk add lua5.1-md5 # apk add lua5.1-cjson # apk add lua5.1-filesystem # apk add lua5.1-bitop # apk add lua5.1-sec You need to make the file system permanent: $ cd /mnt/c/ $ mkdir cmh-ludl $ cd cmh-ludl Now get and install openLuup and AltUI: $ wget https://github.com/akbooer/openLuup/raw/master/Utilities/openLuup_install.lua $ lua5.1 openLuup_install.luaWhen finished (it won't yet return to the command prompt)
access openLuup via the URL: IP:3480/openLuup Update to latest version (Plugins page, type development in Update box) Install VeraBridge (Device Table > Create D_VeraBridge.xml / I_VeraBridge.xml) Add IP of Vera to VeraBridge attributes Reload VeraBridge device > Actions > GetVeraFiles (wait ~2 minutes) ReloadSimple!
-
Evening, all. Hope you're all well.
Did the logging line count / rotation challenge ever get sorted? I'm needing to look back at some historical events and my oldest log is barely 3 hours ago. (Not that I can recall how to try and change the line numbers etc)
Cheers!
C
Delay in luup requests
-
Hi,
I have a couple of luup request, one is a request to VeraAlexa pluging to make alexa speak, the other updating a variable in reactor. They all seem to have a 10-20 second delay
example request
http://192.168.1.134:3480/data_request?id=action&DeviceNum=44&serviceId=urn:toggledbits-com:serviceId:ReactorSensor&action=SetVariable&VariableName=A_home&NewValue=1I can not figure out what is causing the delay, does anyone have any ideas?
-
What does the log show?
-
26.399 openLuup.server:: POST /data_request?id=action&DeviceNum=11&serviceId=urn:toggledbits-com:serviceId:ReactorSensor&action=SetVariable&VariableName=A_home&NewValue=0 HTTP/1.1 tcp{client}: 0xfc90558 2020-11-17 14:53:31.400 luup.call_action:: 11.urn:toggledbits-com:serviceId:ReactorSensor.SetVariable 2020-11-17 14:53:31.401 luup.call_action:: action will be handled by parent: 10 2020-11-17 14:53:31.414 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorSensor.cstate was: {"grpsplfxbw":{"evaledge":{"f":1605524998,"t":1605524998},"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplf... now: {"grpsplfxbw":{"evaledge":{"f":1605524998,"t":1605524998},"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplf... #hooks:0 2020-11-17 14:53:31.419 openLuup.server:: error 'closed' sending 4 bytes to tcp{client}: 0xfc90558 2020-11-17 14:53:31.420 openLuup.server:: ...only 0 bytes sent 2020-11-17 14:53:31.420 openLuup.server:: error 'closed' sending 137 bytes to tcp{client}: 0xfc90558 2020-11-17 14:53:31.421 openLuup.server:: ...only 0 bytes sent 2020-11-17 14:53:31.421 openLuup.server:: error 'closed' sending 2 bytes to tcp{client}: 0xfc90558 2020-11-17 14:53:31.422 openLuup.server:: ...only 0 bytes sent 2020-11-17 14:53:31.422 openLuup.server:: error 'closed' sending 5 bytes to tcp{client}: 0xfc90558 2020-11-17 14:53:31.423 openLuup.server:: ...only 0 bytes sent 2020-11-17 14:53:31.423 openLuup.server:: request completed (137 bytes, 1 chunks, 23 ms) tcp{client}: 0xfc9055 -
OK the issue is the POST request, it does not like it, if i make it GET everything is smooth.
-
No idea.
- I would like to see earlier in the log where there should be an initial connection message from the server module.
- also would like to see the HTTP Server page at
http://openLuupIP:3480/openLuup?page=http - the exact 5 second delay between the first and second lines would indicate a timeout...
- ... but a valid request appears to be received and acted upon (very quickly)
No indication of 10-20 second delays in this case.
Do you always get those errors?
-
@elcid said in Delay in luup requests:
OK the issue is the POST request, it does not like it, if i make it GET everything is smooth.
OK. Our messages crossed, but that's a good start.
What is generating the request? Are you sure it's valid?
-
A get request
2020-11-17 15:45:24.304 luup.variable_set:: 10186.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped was: 0 now: 1 #hooks:1 2020-11-17 15:45:24.305 luup.watch_callback:: 10186.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped called [10]reactorWatch() function: 0xf0d38d0 2020-11-17 15:45:24.321 luup.variable_set:: 14.urn:toggledbits-com:serviceId:ReactorSensor.cstate was: {"condpxw4kq6":{"evaledge":{"t":1605296162,"f":1605296163},"stateedge":{"t":1605296162,"f":1605296163},"id":"condpx... now: {"condpxw4kq6":{"evaledge":{"t":1605296162,"f":1605296163},"stateedge":{"t":1605296162,"f":1605296163},"id":"condpx... #hooks:0 2020-11-17 15:45:24.324 luup.variable_set:: 14.urn:toggledbits-com:serviceId:ReactorSensor.lastacc was: 1605627873 now: 1605627924 #hooks:0 2020-11-17 15:45:24.325 luup.variable_set:: 14.urn:toggledbits-com:serviceId:ReactorSensor.Message was: Not tripped now: Not tripped #hooks:0 2020-11-17 15:45:25.310 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=296260928&Timeout=60&MinimumDelay=1500&_=1605627659979 HTTP/1.1 tcp{client}: 0xf3e3758 2020-11-17 15:45:25.427 openLuup.server:: request completed (40635 bytes, 3 chunks, 116 ms) tcp{client}: 0xf3e3758 2020-11-17 15:45:26.315 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=296260933&Timeout=60&MinimumDelay=1500&_=1605627659980 HTTP/1.1 tcp{client}: 0xf3e3758 2020-11-17 15:45:28.614 luup.variable_set:: 10090.urn:micasaverde-com:serviceId:EnergyMetering1.KWHReading was: 1605627908 now: 1605627928 #hooks:0 2020-11-17 15:45:29.028 openLuup.server:: request completed (17279 bytes, 2 chunks, 2711 ms) tcp{client}: 0xf3e3758 2020-11-17 15:45:30.058 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=296260935&Timeout=60&MinimumDelay=1500&_=1605627659981 HTTP/1.1 tcp{client}: 0xf3e3758 2020-11-17 15:45:38.635 openLuup.io.server:: HTTP:3480 connection from 192.168.1.10 tcp{client}: 0xff28f20 2020-11-17 15:45:38.638 openLuup.server:: GET /data_request?id=action&DeviceNum=11&serviceId=urn:toggledbits-com:serviceId:ReactorSensor&action=SetVariable&VariableName=A_home&NewValue=0 HTTP/1.1 tcp{client}: 0xff28f20 2020-11-17 15:45:38.639 luup.call_action:: 11.urn:toggledbits-com:serviceId:ReactorSensor.SetVariable 2020-11-17 15:45:38.640 luup.call_action:: action will be handled by parent: 10 2020-11-17 15:45:38.652 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorSensor.cstate was: {"grpsplfxbw":{"evaledge":{"f":1605524998,"t":1605524998},"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplf... now: {"grpsplfxbw":{"evaledge":{"f":1605524998,"t":1605524998},"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplf... #hooks:0 2020-11-17 15:45:38.657 openLuup.server:: request completed (137 bytes, 1 chunks, 18 ms) tcp{client}: 0xff28f20 2020-11-17 15:45:38.659 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0xff28f20 2020-11-17 15:45:38.775 openLuup.server:: request completed (43132 bytes, 3 chunks, 8716 ms) tcp{client}: 0xf3e3758 2020-11-17 15:45:39.715 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorSensor.cstate was: {"grpsplfxbw":{"evaledge":{"f":1605524998,"t":1605524998},"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplf... now: {"grpsplfxbw":{"evaledge":{"f":1605524998,"t":1605524998},"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplf... #hooks:0 2020-11-17 15:45:39.719 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorSensor.lastacc was: 1605627571 now: 1605627939 #hooks:0 2020-11-17 15:45:39.722 luup.variable_set:: 10.urn:toggledbits-com:serviceId:Reactor.runscene was: {} now: {} #hooks:0 2020-11-17 15:45:39.724 luup.variable_set:: 10.urn:toggledbits-com:serviceId:Reactor.runscene was: {} now: {"ctx11.scgrpv8xitp8.true":{"starttime":1605627939,"context":11,"scene":"grpv8xitp8.true","taskid":"ctx11.scgrpv8xi... #hooks:0 2020-11-17 15:45:39.727 luup_log:10: Reactor: "Reactor Sensor 1" (#11) Performing "Device Action" ("grpv8xitp8.true" group 1 step 1) 2020-11-17 15:45:39.729 luup.call_action:: 10165.urn:upnp-org:serviceId:SwitchPower1.SetTarget 2020-11-17 15:45:39.731 luup.call_action:: action will be handled by parent: 5 2020-11-17 15:45:39.732 luup.variable_set:: 10.urn:toggledbits-com:serviceId:Reactor.runscene was: {"ctx11.scgrpv8xitp8.true":{"starttime":1605627939,"context":11,"scene":"grpv8xitp8.true","taskid":"ctx11.scgrpv8xi... now: {"ctx11.scgrpv8xitp8.true":{"starttime":1605627939,"context":11,"scene":"grpv8xitp8.true","taskid":"ctx11.scgrpv8xi... #hooks:0 2020-11-17 15:45:39.735 luup.variable_set:: 10.urn:toggledbits-com:serviceId:Reactor.runscene was: {"ctx11.scgrpv8xitp8.true":{"starttime":1605627939,"context":11,"scene":"grpv8xitp8.true","taskid":"ctx11.scgrpv8xi... now: {} #hooks:0 2020-11-17 15:45:39.736 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorGroup.GroupStatus_grpv8xitp8 was: 0 now: 1 #hooks:0 2020-11-17 15:45:39.738 luup.variable_set:: 11.urn:toggledbits-com:sea post request
:10.738 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=296261179&Timeout=60&MinimumDelay=1500&_=1605627660009 HTTP/1.1 tcp{client}: 0xf5f46e0 2020-11-17 15:48:28.610 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorSensor.cstate was: {"grpsplfxbw":{"statestamp":1605524998,"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplfxbw","evalstamp":16... now: {"grpsplfxbw":{"statestamp":1605524998,"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplfxbw","evalstamp":16... #hooks:0 2020-11-17 15:48:28.614 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorSensor.lastacc was: 1605628086 now: 1605628108 #hooks:0 2020-11-17 15:48:28.615 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorSensor.Message was: Not tripped now: Not tripped #hooks:0 2020-11-17 15:48:28.644 luup.variable_set:: 10090.urn:micasaverde-com:serviceId:EnergyMetering1.KWHReading was: 1605628088 now: 1605628108 #hooks:0 2020-11-17 15:48:29.084 openLuup.server:: request completed (69817 bytes, 5 chunks, 18345 ms) tcp{client}: 0xf5f46e0 2020-11-17 15:48:30.151 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=296261184&Timeout=60&MinimumDelay=1500&_=1605627660010 HTTP/1.1 tcp{client}: 0xf5f46e0 2020-11-17 15:48:48.627 luup.variable_set:: 10090.urn:micasaverde-com:serviceId:EnergyMetering1.KWHReading was: 1605628108 now: 1605628128 #hooks:0 2020-11-17 15:48:48.745 openLuup.server:: request completed (33122 bytes, 3 chunks, 18590 ms) tcp{client}: 0xf5f46e0 2020-11-17 15:48:49.782 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=296261186&Timeout=60&MinimumDelay=1500&_=1605627660011 HTTP/1.1 tcp{client}: 0xf5f46e0 2020-11-17 15:48:55.201 openLuup.io.server:: HTTP:3480 connection from 192.168.1.10 tcp{client}: 0xf8bd6d8 2020-11-17 15:48:55.202 openLuup.server:: POST /data_request?id=action&DeviceNum=11&serviceId=urn:toggledbits-com:serviceId:ReactorSensor&action=SetVariable&VariableName=A_home&NewValue=0 HTTP/1.1 tcp{client}: 0xf8bd6d8 2020-11-17 15:49:00.203 luup.call_action:: 11.urn:toggledbits-com:serviceId:ReactorSensor.SetVariable 2020-11-17 15:49:00.204 luup.call_action:: action will be handled by parent: 10 2020-11-17 15:49:00.217 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorSensor.cstate was: {"grpsplfxbw":{"statestamp":1605524998,"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplfxbw","evalstamp":16... now: {"grpsplfxbw":{"statestamp":1605524998,"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplfxbw","evalstamp":16... #hooks:0 2020-11-17 15:49:00.222 openLuup.server:: error 'closed' sending 4 bytes to tcp{client}: 0xf8bd6d8 2020-11-17 15:49:00.223 openLuup.server:: ...only 0 bytes sent 2020-11-17 15:49:00.224 openLuup.server:: error 'closed' sending 137 bytes to tcp{client}: 0xf8bd6d8 2020-11-17 15:49:00.224 openLuup.server:: ...only 0 bytes sent 2020-11-17 15:49:00.225 openLuup.server:: error 'closed' sending 2 bytes to tcp{client}: 0xf8bd6d8 2020-11-17 15:49:00.225 openLuup.server:: ...only 0 bytes sent 2020-11-17 15:49:00.226 openLuup.server:: error 'closed' sending 5 bytes to tcp{client}: 0xf8bd6d8 2020-11-17 15:49:00.226 openLuup.server:: ...only 0 bytes sent 2020-11-17 15:49:00.227 openLuup.server:: request completed (137 bytes, 1 chunks, 23 ms) tcp{client}: 0xf8bd6d8 2020-11-17 15:49:00.228 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0xf8bd6d8 2020-11-17 15:49:00.753 openLuup.server:: request completed (58975 bytes, 4 chunks, 10970 ms) tcp{client}: 0xf5f46e0 2020-11-17 15:49:01.682 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorSensor.cstate was: {"grpsplfxbw":{"statestamp":1605524998,"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplfxbw","evalstamp":16... now: {"grpsplfxbw":{"statestamp":1605524998,"stateedge":{"f":1605524998,"t":1605524998},"id":"grpsplfxbw","evalstamp":16... #hooks:0 2020-11-17 15:49:01.687 luup.variable_set:: 11.urn:toggledbits-com:serviceId:ReactorSensor.lastacc was: 1605628108 now: 1605628141 #hooks:0 2020-11-17 15:49:01.688 luup.variable_set:: 10.urn:toggledbits-com:serviceId:Reactor.runscene was: {} now: {} #hooks:0 2020-11-17 15:49:01.689 luup.variable_set:: 10.urn:toggledbits-com:serviceId:Reactor.runscene was: {} now: {"ctx11.scgrpv8xitp8.true":{"starttime":1605628141,"context":11,"scene":"grpv8xitp8.true","taskid":"ctx11.scgrpv8xi... #hooks:0 2020-11-17 15:49:01.691 luup_log:10: Reactor: "Reactor Sensor 1" (#11) Performing "Device Action" ("grpv8xitp8.true" group 1 step 1) 2020-11-17 15:49:01.691 luup.call_action:: 10165.urn:upnp-org:serviceId:SwitchPower1.SetTathe server page is code 200 for all items wxcept favicon which is 404.
/cgi-bin/cmh/sysinfo.sh 3 200 /openLuup 63 200 D_ALTUI.xml 7 200 D_AltAppStore.xml 7 200 D_BinaryLight1.xml 8 200 D_BluetoothNetwork.xml 6 200 D_BroadLink_Mk2_1.xml 6 200 D_DimmableLight1.xml 6 200 D_DimmableRGBLight1.xml 6 200 D_DoorSensor1.xml 6 200 D_EzloBridge.xml 6 200 D_GenericSensor1.xml 6 200 D_LightSensor1.xml 6 200 D_MotionSensor1.xml 6 200 D_PowerMeter1.xml 9 200 D_Reactor.xml 6 200 D_ReactorDeviceInfo.json 5 200 D_ReactorSensor.xml 6 200 D_SceneController1.xml 9 200 D_SiteSensor1.xml 6 200 D_SmartHomeHelper.xml 6 200 D_Switchboard1.xml 6 200 D_TemperatureSensor1.xml 6 200 D_VeraAlexa1.xml 6 200 D_VeraBridge.xml 6 200 D_WindowCovering1.xml 6 200 D_ZWaveNetwork.xml 6 200 D_ZigbeeNetwork.xml 6 200 D_openLuup.xml 10 200 J_ALTUI_api.js 12 200 J_ALTUI_iphone.js 12 200 J_ALTUI_jquery.ui.touch-punch.min.js 12 200 J_ALTUI_multibox.js 12 200 J_ALTUI_plugins.js 12 200 J_ALTUI_uimgr.js 12 200 J_ALTUI_upnp.js 12 200 J_ALTUI_utils.js 12 200 J_ALTUI_verabox.js 12 200 J_ReactorSensor_ALTUI.js 12 200 J_ReactorSensor_UI7.js 3 200 J_Reactor_ALTUI.js 12 200 J_SiteSensor1_ALTUI.js 12 200 S_HaDevice1.xml 1 200 S_ReactorSensor.xml 1 200 S_SecuritySensor1.xml 1 200 S_SwitchPower1.xml 1 200 favicon.ico 5 404 icons/AltAppStore.svg 7 200 icons/VeraBridge.svg 5 200 icons/dimmable_light_10.png 3 200 icons/dimmable_light_100.png 1 200 icons/dimmable_light_20.png 1 200 icons/dimmable_light_50.png 1 200 icons/dimmable_light_off.png 17 200 icons/door_window_untripped.png 15 200 icons/light_sensor_default.png 13 200 icons/meter_default.png 16 200 icons/motion_sensor_tripped.png 11 200 icons/motion_sensor_untripped.png 13 200 icons/openLuup.svg 66 200 icons/switch_off.png 14 200 icons/switch_on.png 13 200 icons/temperature_sensor_default.png 15 200 icons/window_covering_10.png 13 200 icons/zwave_default.png 15 200 id=action 807 200 id=actions 15 200 id=lr_ALTUI_Handler 36 200 id=lr_ALTUI_LuaRunHandler 154 200 id=lr_HTTP_VeraBridgeMirror_192.168.1.11 0 id=lr_Reactor 24 200 id=lr_SiteSensor 0 id=lr_Switchboard 0 id=lu_action 2 200 id=lu_status2 2158 200 id=scene 1 200 id=sdata 9 200 id=status 3 200 id=user_data 13 200 id=variableget 16 200 id=variableset 12 200 w3.css 60 200having troble with this forum, not allowing image upload.
-
@elcid said in Delay in luup requests:
having troble with this forum, not allowing image upload.
...need to flag this to @DesT
-
Automate is generating the requests when phone leaves home wifi.
-
...so it looks like Automate doesn't like chunked responses to the POST request.
The logs are a bit misleading, because action requests are processed asynchronously as jobs, so things don't always appear in the order that you might expect.. The timeouts should precede the action execution, and they are, almost definitely, what is delaying it.
-
Ok i will have to edit my automate http request forwarder so i can specify request type in the payload. i.e post,get,put,etc
-
@akbooer said in Delay in luup requests:
@elcid said in Delay in luup requests:
having troble with this forum, not allowing image upload.
...need to flag this to @DesT
Are you still having an issue ?
-
@DesT
ye.
seems certain buttons are working.
none of the buttons/icons on reply page.
the 4 black icons to left of reply, above quick reply input.
Also the context menu chevron on the reply button/icon.
i can not edit or delete a post either. -
Dark mode has disappeared and there is no longer an icon in the title bar.
-
Still not working for me @DesT
