-
@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.
-
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
-
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...
-
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?
Openluup control of Alexa
-
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
-
Yep, write two routines, then use my Virtual Devices Plugin to execute the lua code to call them. Use unique and non-friendly names. Something like xyz_light2_on
--
Vera+Zway+Openluup+my own framework
70+ Zwave Devices, a bunch of ZigBee light strips and a lot of codeMy Plug-ins => https://github.com/dbochicchio/vera (VeraAlexa, OpenSprinkler, Virtual Devices, MQTT and much more)
-
@therealdb said in Openluup control of Alexa:
Yep, write two routines, then use my Virtual Devices Plugin to execute the lua code to call them. Use unique and non-friendly names. Something like xyz_light2_on
Thanks. Just skimmed the readme. Not sure how I get this to call Alexa routines? I could just use the Alexa remote control script as well though (which is what I thought of in the shower!)
Cheers
C
-
Hmm, just tried calling a routine (in this case xyzlight) from the Vera Alexa plugin from Reactor.
Although the routine runs fine from the Alexa app nothing happens when I try 'Run routine' from the Reactor.
Question 1 would be 'What should I use for the Device?'
Or is this just not going to work?
TIA
C
-
I’ve not used reactor, so I’m not sure. As I said, you can create a virtual device and run lua. Just use lua:// and the insert the lua code to run the routine
--
Vera+Zway+Openluup+my own framework
70+ Zwave Devices, a bunch of ZigBee light strips and a lot of codeMy Plug-ins => https://github.com/dbochicchio/vera (VeraAlexa, OpenSprinkler, Virtual Devices, MQTT and much more)
-
@therealdb said in Openluup control of Alexa:
I’ve not used reactor, so I’m not sure. As I said, you can create a virtual device and run lua. Just use lua:// and the insert the lua code to run the routine
Thanks, but this is where I'm a bit stuck. I can't see anything in the doc to create a virtual device to map on an Alexa controlled device. Or should I be looking at a virtual http type device direct to the wifi bulb? That being the case I guess I'm going to need to know what the API commands are (which I've not seen being)
Or am I on totally the wrong track?Cheers
C
-
Let's say you have two routines and VeraAlexa already installed. Install Virtual Devices from GitHub (or via AltAppStore) as well. Create a device for Virtual Device Plug-in, then go to the device you created, and insert into variables:
- SetPowerURL: lua://luup.call_action("urn:bochicchio-com:serviceId:VeraAlexa1", "RunRoutine", {RoutineName="xzy_LightOn", GroupZones="Bedroom"}, 666)
Repeat for SetPowerOffURL, but use your lightOff routine name. Change 666 to your VeraAlexa device's ID. Try to turn on, it should call Alexa to do it, same thing for turning off.
-
Thanks!
You are a gent sir. This is what I have in my SetPowerURL variable:
lua://luup.call_action("urn:bochicchio-com:serviceId:VeraAlexa1", "RunRoutine"{RoutineName="xzylight", GroupZones="Office"},22)The routine name is correct and works when accessed from the Alexa App
The device in GroupZones works if I send speech to it
The VeraAlexa device number is correct.Log entry seems sparse, even in debug:
2021-04-22 08:54:40.023 luup.call_action:: 59.urn:upnp-org:serviceId:SwitchPower1.SetTarget 2021-04-22 08:54:40.024 luup_log:59: VirtualDevices[3.0-beta2@59](actionPower@92):actionPower(59,"1") 2021-04-22 08:54:40.024 luup_log:59: VirtualDevices[3.0-beta2@59](actionPowerInternal@45):actionPowerInternal(59,true,true) 2021-04-22 08:54:40.024 luup_log:59: VirtualDevices[3.0-beta2@59](setVar@104):setVar("urn:upnp-org:serviceId:SwitchPower1","Target","1",59) old value "0" 2021-04-22 08:54:40.025 luup.variable_set:: 59.urn:upnp-org:serviceId:SwitchPower1.Target was: 0 now: 1 #hooks:0 2021-04-22 08:54:40.025 luup_log:59: VirtualDevices[3.0-beta2@59](sendDeviceCommand@279):sendDeviceCommand("SetPowerURL","on",59) 2021-04-22 08:54:40.025 luup_log:59: VirtualDevices[3.0-beta2@59]:sendDeviceCommand: RunLua: "luup.call_action(\"urn:bochicchio-com:serviceId:VeraAlexa1\", \"RunRoutine\", {RoutineName=\"xzylight\", GroupZones=\"Office\"},22)" 2021-04-22 08:54:40.025 luup.call_action:: 1.urn:micasaverde-com:serviceId:HomeAutomationGateway1.RunLua 2021-04-22 08:54:40.025 luup_log:59: VirtualDevices[3.0-beta2@59](setVar@104):setVar("urn:upnp-org:serviceId:SwitchPower1","Status","1",59) old value "0" 2021-04-22 08:54:40.025 luup.variable_set:: 59.urn:upnp-org:serviceId:SwitchPower1.Status was: 0 now: 1 #hooks:0 2021-04-22 08:54:40.026 luup_log:59: VirtualDevices[3.0-beta2@59](onSuccess@77):Auto off in 0 secsWhat have I done wrong?
TIA
C
The Ex-Vera abuser know as CatmanV2.....
-
-
Of course:
Variable Value AlexaHost layla.amazon.co.uk AmazonHost amazon.co.uk AnnouncementVolume 50 CommFailure 0 CommFailureTime 0 Configured 1 CurrentVersion 0.2.13 DebugMode 0 DefaultBreak 3 DefaultEcho Office DefaultVolume 40 Language en-GB LatestResponse sending cmd:speak:<s>There is movement at the front door</s><break time="0s" /> to dev:Office type:A32DOYMUN6DTXA serial:G090U50991550NLS customerid:A1CVTZEBJIUFJI OneTimePassCode Password **** UseAnnoucements 1 Username *****C
The Ex-Vera abuser know as CatmanV2.....
-
@CatmanV2 @LibraSun can you please send me more logs (see Patrick's guidance). Privately is OK, if you prefer. Remember to set DebugMode to 1 for Vera Alexa's device. It's almost week-end, so I'll have some spare time. Thanks!
--
Vera+Zway+Openluup+my own framework
70+ Zwave Devices, a bunch of ZigBee light strips and a lot of codeMy Plug-ins => https://github.com/dbochicchio/vera (VeraAlexa, OpenSprinkler, Virtual Devices, MQTT and much more)
-
@therealdb said in Openluup control of Alexa:
@CatmanV2 @LibraSun can you please send me more logs (see Patrick's guidance). Privately is OK, if you prefer. Remember to set DebugMode to 1 for Vera Alexa's device. It's almost week-end, so I'll have some spare time. Thanks!
For sure! But given that I have no idea what (other than what posted) is relevant how long a chunk do you want?
C
-
Hmm, PM limit is 1000 characters
2021-04-23 17:52:38.268 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0 2021-04-23 17:52:38.268 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0 2021-04-23 17:52:38.269 luup_log:52: SiteSensor: Scheduling next activity in 60 seconds 2021-04-23 17:52:38.778 openLuup.server:: request completed (10747 bytes, 1 chunks, 7579 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:38.784 openLuup.server:: request completed (10747 bytes, 1 chunks, 7026 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:52:39.287 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175518&Timeout=60&MinimumDelay=1500&_=1618778104503 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:39.984 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175518&Timeout=60&MinimumDelay=1500&_=1619187656551 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:52:42.859 openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=61&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1 HTTP/1.1 tcp{client}: 0x564e8c87b0f8 2021-04-23 17:52:42.860 luup.call_action:: 61.urn:upnp-org:serviceId:SwitchPower1.SetTarget 2021-04-23 17:52:42.860 luup.variable_set:: 61.urn:upnp-org:serviceId:SwitchPower1.Target was: 0 now: 1 #hooks:0 2021-04-23 17:52:42.861 luup_log:61: VirtualDevices[3.0-beta2@61]:sendDeviceCommand: RunLua: "luup.call_action(\"urn:bochicchio-com:serviceId:VeraAlexa1\", \"RunRoutine\", {RoutineName=\"xzylight\", GroupZones=\"Office\"},22)" 2021-04-23 17:52:42.861 luup.call_action:: 1.urn:micasaverde-com:serviceId:HomeAutomationGateway1.RunLua 2021-04-23 17:52:42.861 luup.variable_set:: 61.urn:upnp-org:serviceId:SwitchPower1.Status was: 0 now: 1 #hooks:0 2021-04-23 17:52:42.861 openLuup.server:: request completed (35 bytes, 1 chunks, 2 ms) tcp{client}: 0x564e8c87b0f8 2021-04-23 17:52:43.067 openLuup.server:: request completed (6489 bytes, 1 chunks, 3779 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:43.078 openLuup.server:: GET /cmh/skins/default/img/devices/device_states/binary_light_on.png HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:43.079 openLuup.server:: request completed (708 bytes, 0 chunks, 0 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:43.180 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175520&Timeout=60&MinimumDelay=1500&_=1618778104504 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:43.228 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656552 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:52:43.334 openLuup.server:: request completed (6489 bytes, 1 chunks, 3349 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:52:43.335 openLuup.server:: request completed (1 bytes, 1 chunks, 106 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:52:43.714 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175520&Timeout=60&MinimumDelay=1500&_=1619187656553 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:52:45.721 luup.variable_set:: 20380.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 22 now: 23 #hooks:0 2021-04-23 17:52:45.930 openLuup.server:: request completed (7817 bytes, 1 chunks, 2215 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:52:46.036 openLuup.server:: request completed (7817 bytes, 1 chunks, 2855 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:46.163 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175521&Timeout=60&MinimumDelay=1500&_=1618778104505 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:46.913 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175521&Timeout=60&MinimumDelay=1500&_=1619187656554 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:52:48.927 luup.variable_set:: 20380.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 23 now: 22 #hooks:0 2021-04-23 17:52:49.135 openLuup.server:: request completed (7817 bytes, 1 chunks, 2221 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:52:49.442 openLuup.server:: request completed (7817 bytes, 1 chunks, 3278 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:49.786 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175522&Timeout=60&MinimumDelay=1500&_=1619187656555 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:52:50.160 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175522&Timeout=60&MinimumDelay=1500&_=1618778104506 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:53.217 luup.variable_set:: 20380.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 22 now: 23 #hooks:0 2021-04-23 17:52:53.422 openLuup.server:: request completed (7817 bytes, 1 chunks, 3261 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:53.629 openLuup.server:: request completed (7817 bytes, 1 chunks, 3841 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:52:53.634 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656556 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:52:53.736 openLuup.server:: request completed (1 bytes, 1 chunks, 101 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:52:53.978 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175523&Timeout=60&MinimumDelay=1500&_=1618778104507 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:52:54.991 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175523&Timeout=60&MinimumDelay=1500&_=1619187656557 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:52:59.789 openLuup.server:: GET /cmh/skins/default/img/devices/device_states/switch_on.png HTTP/1.1 tcp{client}: 0x564e8c87b0f8 2021-04-23 17:52:59.790 openLuup.server:: request completed (1223 bytes, 0 chunks, 0 ms) tcp{client}: 0x564e8c87b0f8 2021-04-23 17:52:59.791 openLuup.server:: GET /cmh/skins/default/img/devices/device_states/switch_off.png HTTP/1.1 tcp{client}: 0x564e8cd027f8 2021-04-23 17:52:59.792 openLuup.server:: request completed (1191 bytes, 0 chunks, 0 ms) tcp{client}: 0x564e8cd027f8 2021-04-23 17:53:04.775 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656558 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:53:04.877 openLuup.server:: request completed (1 bytes, 1 chunks, 101 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:53:05.036 luup.variable_set:: 20380.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 23 now: 22 #hooks:0 2021-04-23 17:53:05.143 openLuup.server:: request completed (7817 bytes, 1 chunks, 10151 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:05.249 openLuup.server:: request completed (7817 bytes, 1 chunks, 11270 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:53:05.782 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175524&Timeout=60&MinimumDelay=1500&_=1619187656559 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:06.573 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175524&Timeout=60&MinimumDelay=1500&_=1618778104508 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:53:09.329 luup.variable_set:: 20380.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 22 now: 23 #hooks:0 2021-04-23 17:53:09.638 openLuup.server:: request completed (7817 bytes, 1 chunks, 3854 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:09.844 openLuup.server:: request completed (7817 bytes, 1 chunks, 3270 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:53:10.183 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175525&Timeout=60&MinimumDelay=1500&_=1618778104509 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:53:10.982 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175525&Timeout=60&MinimumDelay=1500&_=1619187656560 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:13.659 luup.variable_set:: 20380.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 23 now: 22 #hooks:0 2021-04-23 17:53:13.766 openLuup.server:: request completed (7817 bytes, 1 chunks, 2782 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:14.073 openLuup.server:: request completed (7817 bytes, 1 chunks, 3888 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:53:14.978 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175526&Timeout=60&MinimumDelay=1500&_=1619187656561 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:14.979 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656562 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:53:15.081 openLuup.server:: request completed (1 bytes, 1 chunks, 101 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:53:15.548 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175526&Timeout=60&MinimumDelay=1500&_=1618778104510 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:53:26.088 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656563 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:53:26.190 openLuup.server:: request completed (1 bytes, 1 chunks, 101 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:53:29.500 luup.variable_set:: 25005.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 27.4 now: 26.6 #hooks:2 2021-04-23 17:53:29.501 luup.watch_callback:: 25005.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature called [20]DataWatcherCallback() function: 0x564e8c4004e0 2021-04-23 17:53:29.501 luup.watch_callback:: 25005.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature called [11]reactorWatch() function: 0x564e8ba75720 2021-04-23 17:53:29.508 luup.variable_set:: 23.urn:toggledbits-com:serviceId:ReactorSensor.cstate was: {"condso4rr22":{"evaledge":{"f":1616784363},"stateedge":{"f":1616784363},"id":"condso4rr22","evalstamp":1616784363,... now: {"condso4rr22":{"evaledge":{"f":1616784363},"stateedge":{"f":1616784363},"id":"condso4rr22","evalstamp":1616784363,... #hooks:0 2021-04-23 17:53:29.510 luup.variable_set:: 23.urn:toggledbits-com:serviceId:ReactorSensor.Message was: now: #hooks:0 2021-04-23 17:53:29.927 openLuup.server:: request completed (74198 bytes, 5 chunks, 14948 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:29.933 openLuup.server:: request completed (74198 bytes, 5 chunks, 14384 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:53:30.179 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175529&Timeout=60&MinimumDelay=1500&_=1618778104511 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:53:30.903 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175529&Timeout=60&MinimumDelay=1500&_=1619187656564 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:38.278 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.LastRun was: 1619196758 now: 1619196818 #hooks:0 2021-04-23 17:53:38.278 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.LastQuery was: 1619196758 now: 1619196818 #hooks:0 2021-04-23 17:53:38.279 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.LastEval was: 1619196758 now: 1619196818 #hooks:0 2021-04-23 17:53:38.279 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.Message was: Valid response; matched! now: Performing query... #hooks:0 2021-04-23 17:53:38.280 luup_log:52: SiteSensor: HTTP "GET" "http://192.168.70.52", headers={ } 2021-04-23 17:53:38.280 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.LogCapture was: 17:52:38: SiteSensor: HTTP "GET" "http://192.168.70.52", headers={ }|17:52:38: SiteSensor: Request succeeded, "wit... now: 17:53:38: SiteSensor: HTTP "GET" "http://192.168.70.52", headers={ } #hooks:0 2021-04-23 17:53:38.298 luup_log:52: SiteSensor: Request succeeded, "with" match: "Matched" 2021-04-23 17:53:38.298 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.LogCapture was: 17:53:38: SiteSensor: HTTP "GET" "http://192.168.70.52", headers={ } now: 17:53:38: SiteSensor: HTTP "GET" "http://192.168.70.52", headers={ }|17:53:38: SiteSensor: Request succeeded, "wit... #hooks:0 2021-04-23 17:53:38.299 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.Message was: Performing query... now: Valid response; matched! #hooks:0 2021-04-23 17:53:38.299 luup.set_failure:: status = 0 2021-04-23 17:53:38.300 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0 2021-04-23 17:53:38.300 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0 2021-04-23 17:53:38.301 luup_log:52: SiteSensor: Scheduling next activity in 60 seconds 2021-04-23 17:53:38.407 openLuup.server:: request completed (10747 bytes, 1 chunks, 7504 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:38.413 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656565 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:38.515 openLuup.server:: request completed (1 bytes, 1 chunks, 101 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:38.617 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175538&Timeout=60&MinimumDelay=1500&_=1619187656566 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:38.825 openLuup.server:: request completed (10747 bytes, 1 chunks, 8644 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:53:39.243 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175538&Timeout=60&MinimumDelay=1500&_=1618778104512 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:53:49.600 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656567 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:53:49.702 openLuup.server:: request completed (1 bytes, 1 chunks, 101 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:53:59.552 luup.variable_set:: 23.urn:toggledbits-com:serviceId:ReactorSensor.cstate was: {"condso4rr22":{"evaledge":{"f":1616784363},"stateedge":{"f":1616784363},"id":"condso4rr22","evalstamp":1616784363,... now: {"condso4rr22":{"statestamp":1616784363,"stateedge":{"f":1616784363},"id":"condso4rr22","evalstamp":1616784363,"las... #hooks:0 2021-04-23 17:53:59.553 luup.variable_set:: 23.urn:toggledbits-com:serviceId:ReactorSensor.Message was: now: #hooks:0 2021-04-23 17:53:59.870 openLuup.server:: request completed (73276 bytes, 5 chunks, 21252 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:53:59.983 openLuup.server:: request completed (73276 bytes, 5 chunks, 20739 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:54:00.195 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175540&Timeout=60&MinimumDelay=1500&_=1618778104513 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:54:00.910 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656568 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:54:00.912 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175540&Timeout=60&MinimumDelay=1500&_=1619187656569 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:54:01.014 openLuup.server:: request completed (1 bytes, 1 chunks, 102 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:54:02.941 luup_log:0: 13Mb, 2.1%cpu, 1.3days 2021-04-23 17:54:03.046 openLuup.server:: request completed (4875 bytes, 1 chunks, 2850 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:54:03.151 openLuup.server:: request completed (4875 bytes, 1 chunks, 2238 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:54:03.658 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175547&Timeout=60&MinimumDelay=1500&_=1619187656570 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:54:04.463 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175547&Timeout=60&MinimumDelay=1500&_=1618778104514 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:54:14.604 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656571 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:54:14.706 openLuup.server:: request completed (1 bytes, 1 chunks, 101 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:54:29.889 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656572 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:54:29.992 openLuup.server:: request completed (1 bytes, 1 chunks, 102 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:54:31.696 openLuup.io.server:: HTTP:3480 connection closed EXPIRED tcp{client}: 0x564e8c87b0f8 2021-04-23 17:54:33.054 luup_log:26: IPhoneLocator: Entering loop:26:1 2021-04-23 17:54:34.257 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.PrevUpdate was: 1619195975.93 now: 1619196282.895 #hooks:0 2021-04-23 17:54:34.258 luup.variable_set:: 26.urn:micasaverde-com:serviceId:HaDevice1.LastUpdate was: 1619196282.895 now: 1619196597.36 #hooks:0 2021-04-23 17:54:34.258 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.PrevLat was: 51.762584709398 now: 51.762616462252 #hooks:0 2021-04-23 17:54:34.258 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.PrevLong was: 0.13431196000302 now: 0.13432520872469 #hooks:0 2021-04-23 17:54:34.258 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.CurLat was: 51.762616462252 now: 51.762606422089 #hooks:0 2021-04-23 17:54:34.258 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.CurLong was: 0.13432520872469 now: 0.13428539975898 #hooks:0 2021-04-23 17:54:34.258 luup_log:26: IPhoneLocator: ETA set to =>0 2021-04-23 17:54:34.258 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.LocationExtraInfo was: GPS:9.9140666521856:false now: GPS:8.4249524283522:false #hooks:0 2021-04-23 17:54:34.259 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.MsgText was: Poll: 2021-04-23 17:49 / 300 s now: Poll: 2021-04-23 17:54 #hooks:0 2021-04-23 17:54:34.259 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.MsgText2 was: -0.00 Km @ 0.00 Km/h on 2021-04-23 17:44 now: -0.00 Km @ 0.00 Km/h on 2021-04-23 17:49 #hooks:0 2021-04-23 17:54:34.259 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.MapUrl was: https://dev.virtualearth.net/REST/v1/Imagery/Map/Road?pushpin=51.762616462252,0.13432520872469;;H&mapLayer=TrafficF... now: https://dev.virtualearth.net/REST/v1/Imagery/Map/Road?pushpin=51.762606422089,0.13428539975898;;H&mapLayer=TrafficF... #hooks:0 2021-04-23 17:54:34.259 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.ICloudDevices was: iPhone,Chris’s MacBook Air (2),New Mail Server,iPad (7) now: iPhone,Chris’s MacBook Air (2),New Mail Server,iPad (7) #hooks:0 2021-04-23 17:54:34.259 luup_log:26: IPhoneLocator: getPeriodForDevice(26) - Distance:-0 Auto:1 Base:300==>300 2021-04-23 17:54:34.259 luup.variable_set:: 26.urn:upnp-org:serviceId:IPhoneLocator1.MsgText was: Poll: 2021-04-23 17:54 now: Poll: 2021-04-23 17:54 / 300 s #hooks:0 2021-04-23 17:54:34.260 luup.call_timer:: interval: time=301, days={} 2021-04-23 17:54:34.309 openLuup.io.server:: HTTP:3480 connection closed EXPIRED tcp{client}: 0x564e8cd027f8 2021-04-23 17:54:34.313 openLuup.server:: request completed (10211 bytes, 1 chunks, 30654 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:54:34.315 openLuup.server:: request completed (10211 bytes, 1 chunks, 29850 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:54:34.655 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175559&Timeout=60&MinimumDelay=1500&_=1619187656573 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:54:35.560 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175559&Timeout=60&MinimumDelay=1500&_=1618778104515 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:54:38.381 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.LastRun was: 1619196818 now: 1619196878 #hooks:0 2021-04-23 17:54:38.381 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.LastQuery was: 1619196818 now: 1619196878 #hooks:0 2021-04-23 17:54:38.382 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.LastEval was: 1619196818 now: 1619196878 #hooks:0 2021-04-23 17:54:38.382 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.Message was: Valid response; matched! now: Performing query... #hooks:0 2021-04-23 17:54:38.383 luup_log:52: SiteSensor: HTTP "GET" "http://192.168.70.52", headers={ } 2021-04-23 17:54:38.383 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.LogCapture was: 17:53:38: SiteSensor: HTTP "GET" "http://192.168.70.52", headers={ }|17:53:38: SiteSensor: Request succeeded, "wit... now: 17:54:38: SiteSensor: HTTP "GET" "http://192.168.70.52", headers={ } #hooks:0 2021-04-23 17:54:38.400 luup_log:52: SiteSensor: Request succeeded, "with" match: "Matched" 2021-04-23 17:54:38.400 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.LogCapture was: 17:54:38: SiteSensor: HTTP "GET" "http://192.168.70.52", headers={ } now: 17:54:38: SiteSensor: HTTP "GET" "http://192.168.70.52", headers={ }|17:54:38: SiteSensor: Request succeeded, "wit... #hooks:0 2021-04-23 17:54:38.401 luup.variable_set:: 52.urn:toggledbits-com:serviceId:SiteSensor1.Message was: Performing query... now: Valid response; matched! #hooks:0 2021-04-23 17:54:38.401 luup.set_failure:: status = 0 2021-04-23 17:54:38.401 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0 2021-04-23 17:54:38.402 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0 2021-04-23 17:54:38.402 luup_log:52: SiteSensor: Scheduling next activity in 60 seconds 2021-04-23 17:54:38.858 openLuup.server:: request completed (10747 bytes, 1 chunks, 3297 ms) tcp{client}: 0x564e8bf913d8 2021-04-23 17:54:38.964 openLuup.server:: request completed (10747 bytes, 1 chunks, 4308 ms) tcp{client}: 0x564e8c234198 2021-04-23 17:54:39.232 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175568&Timeout=60&MinimumDelay=1500&_=1618778104516 HTTP/1.1 tcp{client}: 0x564e8bf913d8 2021-04-23 17:54:39.895 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=82175568&Timeout=60&MinimumDelay=1500&_=1619187656574 HTTP/1.1 tcp{client}: 0x564e8c234198 2021-04-23 17:54:40.607 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656575 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:54:40.709 openLuup.server:: request completed (1 bytes, 1 chunks, 101 ms) tcp{client}: 0x564e8c6b7358 2021-04-23 17:54:52.893 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1619187656576 HTTP/1.1 tcp{client}: 0x564e8c6b7358 2021-04-23 17:54:52.995 openLuup.server:: request completed (1 bytes, 1 chunks, 101 ms) tcp{client}: 0x564e8c6b7358That's two minutes, let me know if you need more
C
The Ex-Vera abuser know as CatmanV2.....
-
@catmanv2 I just need a couple of logs around the invocation of run routine. Thanks!
--
Vera+Zway+Openluup+my own framework
70+ Zwave Devices, a bunch of ZigBee light strips and a lot of codeMy Plug-ins => https://github.com/dbochicchio/vera (VeraAlexa, OpenSprinkler, Virtual Devices, MQTT and much more)
-
@therealdb said in Openluup control of Alexa:
@catmanv2 I just need a couple of logs around the invocation of run routine. Thanks!
OK, I'm being dumb. Is that not what I just posted?
17:52:42.860Device 61 is the virtual device...
C
The Ex-Vera abuser know as CatmanV2.....
-
@catmanv2 you posted device #61 (Virtual Device), but I definitely need device #22 (VeraAlexa) to have DebugMode to 1 and its logs. Thanks!
--
Vera+Zway+Openluup+my own framework
70+ Zwave Devices, a bunch of ZigBee light strips and a lot of codeMy Plug-ins => https://github.com/dbochicchio/vera (VeraAlexa, OpenSprinkler, Virtual Devices, MQTT and much more)
-
@therealdb Cheers!
OK Debug is on on device 22, and has been for some time
Is there another log file for VeraAlexa? That's my LuaUPnP.log . Raw and un-adulterated. Simply copied from the terminal from
#tail -F LuaUPnP.logC
The Ex-Vera abuser know as CatmanV2.....
-
@catmanv2 nope, no other log files. So, it seems that RunLua is not executing correctly. I'll take a look at this, to start. What's your version of openLuup?
--
Vera+Zway+Openluup+my own framework
70+ Zwave Devices, a bunch of ZigBee light strips and a lot of codeMy Plug-ins => https://github.com/dbochicchio/vera (VeraAlexa, OpenSprinkler, Virtual Devices, MQTT and much more)
-
@therealdb said in Openluup control of Alexa:
@catmanv2 nope, no other log files. So, it seems that RunLua is not executing correctly. I'll take a look at this, to start. What's your version of openLuup?
According to the panel:
20.6.20I can't help but notice that the password stored in the VeraAlexa variables is not my password any longer.....
Could this have a bearing? Seems to make no difference to TTS.....
And updated, no difference
C
The Ex-Vera abuser know as CatmanV2.....
-
@catmanv2 I don't think it will make any difference. I'll try to replicate your setup later today or tomorrow. We'll definitely fix it
--
Vera+Zway+Openluup+my own framework
70+ Zwave Devices, a bunch of ZigBee light strips and a lot of codeMy Plug-ins => https://github.com/dbochicchio/vera (VeraAlexa, OpenSprinkler, Virtual Devices, MQTT and much more)