-
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 ? -
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.
-
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. 🙂
-
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...
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
