On start up the log indicates the following:
2023-12-19 10:17:12.588 luup_log:209: VirtualDevices[3.0-beta7@209](setVar@104):setVar("urn:upnp-org:serviceId:Dimming1","LoadLevelTarget","",209) old value ""
2023-12-19 10:17:12.589 luup_log:209: VirtualDevices[3.0-beta7@209](setVar@104):setVar("urn:upnp-org:serviceId:Dimming1","LoadLevelTarget","",209) old value ""
2023-12-19 10:17:12.589 luup_log:209: VirtualDevices[3.0-beta7@209](setVar@104):setVar("urn:upnp-org:serviceId:Dimming1","LoadLevelStatus","",209) old value ""
2023-12-19 10:17:12.589 luup_log:209: VirtualDevices[3.0-beta7@209](setVar@104):setVar("urn:upnp-org:serviceId:Dimming1","LoadLevelLast","",209) old value ""
2023-12-19 10:17:12.589 luup_log:209: VirtualDevices[3.0-beta7@209](setVar@104):setVar("urn:upnp-org:serviceId:Dimming1","TurnOnBeforeDim","",209) old value ""
2023-12-19 10:17:12.590 luup_log:209: VirtualDevices[3.0-beta7@209](setVar@104):setVar("urn:upnp-org:serviceId:Dimming1","AllowZeroLevel","",209) old value ""
2023-12-19 10:17:12.590 luup_log:209: VirtualDevices[3.0-beta7@209](setVar@104):setVar("urn:bochicchio-com:serviceId:VirtualBinaryLight1","SetBrightnessURL","",209) old value ""
2023-12-19 10:17:12.590 luup_log:209: VirtualDevices[3.0-beta7@209](initializeMqtt@421):initializeMqtt(209,{ PowerStatusOff={ Value="0", Service="urn:upnp-org:serviceId:SwitchPower1", Variable="Status" }, BrightnessValue={ Variable="LoadLevelStatus", Service="urn:upnp-org:serviceId:Dimming1" }, PowerStatusOn={ Value="1", Service="urn:upnp-org:serviceId:SwitchPower1", Variable="Status" } }) - openLuup: true
2023-12-19 10:17:12.591 luup_log:209: VirtualDevices[3.0-beta7@209](subscribeToMqtt@414):subscribeToMqtt(209,nil,{ deviceID=209, opts={ Value="0", Service="urn:upnp-org:serviceId:SwitchPower1", Variable="Status" } })
2023-12-19 10:17:12.591 openLuup.context_switch:: ERROR: [dev #209] ./L_VirtualLibrary.lua:415: attempt to concatenate field 'topic' (a nil value)
2023-12-19 10:17:12.591 openLuup.scheduler:: job aborted : ./L_VirtualLibrary.lua:415: attempt to concatenate field 'topic' (a nil value)
The MQTT variables are all set to "skip":
MQTT_BrightnessValue
MQTT_PowerStatusOff
MQTT_PowerStatusOn
However it looks like the code doesn't check for "skip" and executes the functions initializeMqtt() and subscribeToMqtt() disappearing into the weeds at that point as there is nothing to subscribe to.
It would also be good if the code treated an empty string in the same way as it uses the key word "skip". It's not obvious that "skip" needs to be explicitly used.
I still use Vera controllers in combination with ReactorSensors. I have several Reactor sensors in use to retrieve weather data from Wunderground (i have a personal weather station), my smartmeter etc.
Recently I installed solar panels with a SolarEdge inverter. SolarEdge has an API to retrieve my power production data from their cloud.
Output is in json.
So I created a new Reactor Sensor. Connection is working (query okay).
But I encounter problems at the Value Expressions. Either I get ""query okay" but no data or I get "query okay but 1 expressions failed"
This is the json output
{"overview":{"lastUpdateTime":"2023-05-12 10:45:57","lifeTimeData":{"energy":476310.0,"revenue":216.577},"lastYearData":{"energy":433001.0},"lastMonthData":{"energy":433001.0},"lastDayData":{"energy":8262.0},"currentPower":{"power":5647.0},"measuredBy":"INVERTER"}}
So it has different layers/levels.
I tried to put in the Value Expressions field several combinations to get the energy data of today (8262.0), like:
response.lastDayData.energy
response.overview.lastDayData.energy
response.overview.lastUpdateTime.lastDayData.energy
all fail...
Who can help me with this ?
Just seen notification to Netatmo developers that the current password-based login is being disabled as from October.
Oath2 is now a requirement for apps needing access to Netatmo. This will require some changes to my venerable plug-in. I’m not sure how easy this will be with the current libraries in use.
Does anyone out there use the Netatmo plug-in?
Does anyone have any advice on using Oath2?
Anyone else seeing issues with Vera TTS? All was working fine. I assumed the cookie had expired, but even having replaced it, and seeing that the .alexa.login file is aging (as I'd expect) No speech.
I seem to be getting an odd timeout but no idea from where.
Debian Bullseye, bare metal
Good call from this morning:
2023-01-18 08:22:51.657 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x563e8a2345e8
2023-01-18 08:22:51.667 openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x563e89df13d8
2023-01-18 08:22:51.668 openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=31085221&MinimumDelay=50&output_format=json&_r=1674030171666 HTTP/1.1 tcp{client}: 0x563e89df13d8
2023-01-18 08:22:58.223 openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x563e8a4ab388
2023-01-18 08:22:58.223 openLuup.server:: GET /data_request?Text=Rachel%20has%20arrived%20at%20Washtec&Language=en-GB&GroupZones=Everywhere&Volume=50&DeviceNum=22&id=action&serviceId=urn%3Abochicchio-com%3AserviceId%3AVeraAlexa1&action=
Say&output_format=json&_r=1674030178221 HTTP/1.1 tcp{client}: 0x563e8a4ab388
2023-01-18 08:22:58.224 luup.call_action:: 22.urn:bochicchio-com:serviceId:VeraAlexa1.Say
2023-01-18 08:22:58.224 luup_log:22: VeraAlexa: addToQueue: added to queue for 22
2023-01-18 08:23:09.379 luup.variable_set:: 22.urn:bochicchio-com:serviceId:VeraAlexa1.LatestResponse was: sending cmd:speak:<s><lang xml:lang="en-UK"><amazon:domain name="conversational">The temperature outside is -3 degr... now: sendi
ng cmd:speak:<s>Rachel has arrived at Washtec</s><break time="0s" /> to dev:Everywhere type:A3C9PE6TNYLTCH ser... #hooks:0
2023-01-18 08:23:09.381 openLuup.server:: request completed (29 bytes, 1 chunks, 11156 ms) tcp{client}: 0x563e8a4ab388
2023-01-18 08:23:09.391 luup.variable_set:: 25001.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped was: 0 now: 1 #hooks:0
2023-01-18 08:23:09.391 luup.variable_set:: 25001.urn:micasaverde-com:serviceId:SecuritySensor1.LastTrip was: 1674030032 now: 1674030189 #hooks:0
2023-01-18 08:23:09.394 openLuup.server:: request completed (1389 bytes, 1 chunks, 31782 ms) tcp{client}: 0x563e897eefd8
2023-01-18 08:23:09.395 openLuup.server:: request completed (1389 bytes, 1 chunks, 31662 ms) tcp{client}: 0x563e8a7c5248
2023-01-18 08:23:09.396 openLuup.server:: request completed (1389 bytes, 1 chunks, 17728 ms) tcp{client}: 0x563e89df13d8
2023-01-18 08:23:09.396 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x563e8a4ab388
2023-01-18 08:23:09.411 openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x563e8a13f3c8
2023-01-18 08:23:09.412 openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x563e8a79f3c8
2023-01-18 08:23:09.412 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x563e89df13d8
2023-01-18 08:23:09.413 openLuup.server:: GET /data_request?newTargetValue=1&DeviceNum=20330&id=action&serviceId=urn%3Aupnp-org%3AserviceId%3ASwitchPower1&action=SetTarget&output_format=json&_r=1674030189410 HTTP/1.1 tcp{client}: 0x563e
8a13f3c8
2023-01-18 08:23:09.413 openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=31085224&MinimumDelay=50&output_format=json&_r=1674030189411 HTTP/1.1 tcp{client}: 0x563e8a79f3c8
2023-01-18 08:23:09.413 luup.call_action:: 20330.urn:upnp-org:serviceId:SwitchPower1.SetTarget
2023-01-18 08:23:09.413 luup.call_action:: action will be handled by parent: 37
2023-01-18 08:23:09.413 luup.variable_set:: 20330.urn:upnp-org:serviceId:SwitchPower1.Target was: 1 now: 1 #hooks:0
2023-01-18 08:23:09.449 openLuup.server:: request completed (35 bytes, 1 chunks, 36 ms) tcp{client}: 0x563e8a13f3c8
2023-01-18 08:23:09.461 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x563e8a13f3c8
2023-01-18 08:23:09.564 openLuup.server:: request completed (819 bytes, 1 chunks, 151 ms) tcp{client}: 0x563e8a79f3c8
2023-01-18 08:23:09.569 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x563e8a79f3c8
2023-01-18 08:23:09.581 openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x563e8a32bf28
Bad request from just now:
2023-01-18 18:29:26.695 openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x557239889e58
2023-01-18 18:29:26.696 openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=66503545&MinimumDelay=50&output_format=json&_r=1674066566691 HTTP/1.1 tcp{client}: 0x557239889e58
2023-01-18 18:29:26.799 openLuup.server:: request completed (833 bytes, 1 chunks, 2249 ms) tcp{client}: 0x557239a62f78
2023-01-18 18:29:26.911 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=66503545&Timeout=60&MinimumDelay=1500&_=1674030721531 HTTP/1.1 tcp{client}: 0x5572385f78d8
2023-01-18 18:29:27.028 openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x557238b98c58
2023-01-18 18:29:27.029 openLuup.server:: GET /data_request?Text=Testing...1...2...3&Language=en-GB&GroupZones=Everywhere&Volume=50&DeviceNum=22&id=action&serviceId=urn%3Abochicchio-com%3AserviceId%3AVeraAlexa1&action=Say&output_format=json&_r=1674066567027 HTTP/1.1 tcp{client}: 0x557238b98c58
2023-01-18 18:29:27.029 luup.call_action:: 22.urn:bochicchio-com:serviceId:VeraAlexa1.Say
2023-01-18 18:29:27.029 luup_log:22: VeraAlexa: addToQueue: added to queue for 22
2023-01-18 18:29:43.149 openLuup.server:: error 'closed' sending 4 bytes to tcp{client}: 0x557238b98c58
2023-01-18 18:29:43.150 openLuup.server:: ...only 0 bytes sent
2023-01-18 18:29:43.150 openLuup.server:: error 'closed' sending 29 bytes to tcp{client}: 0x557238b98c58
2023-01-18 18:29:43.150 openLuup.server:: ...only 0 bytes sent
2023-01-18 18:29:43.150 openLuup.server:: error 'closed' sending 2 bytes to tcp{client}: 0x557238b98c58
2023-01-18 18:29:43.150 openLuup.server:: ...only 0 bytes sent
2023-01-18 18:29:43.150 openLuup.server:: error 'closed' sending 5 bytes to tcp{client}: 0x557238b98c58
2023-01-18 18:29:43.150 openLuup.server:: ...only 0 bytes sent
2023-01-18 18:29:43.150 openLuup.server:: request completed (29 bytes, 1 chunks, 16121 ms) tcp{client}: 0x557238b98c58
2023-01-18 18:29:43.153 luup_log:63: BroadLink_Mk2 debug: RM3 Mini - IR 1: device is not a sensor or if a sensor; is not coded for
2023-01-18 18:29:43.153 luup_log:63: BroadLink_Mk2 debug: RM3 Mini - IR 1: veraId: 64, blId: a0:43:b0:8b:e0:e5, altId: a0:43:b0:8b:e0:e5_ir
2023-01-18 18:29:43.153 luup_log:63: BroadLink_Mk2 debug: RM3 Mini - IR 1: urn:schemas-micasaverde-com:device:IrTransmitter:1
2023-01-18 18:29:43.154 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=66503545&Timeout=60&MinimumDelay=1500&_=1674066518681 HTTP/1.1 tcp{client}: 0x557239a62f78
2023-01-18 18:29:43.155 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x557238b98c58
2023-01-18 18:29:43.157 openLuup.server:: request completed (591 bytes, 1 chunks, 16460 ms) tcp{client}: 0x557239889e58
2023-01-18 18:29:43.161 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x557239889e58
2023-01-18 18:29:43.175 openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x5572399f30e8
2023-01-18 18:29:43.176 openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=66503545&MinimumDelay=50&output_format=json&_r=1674066583172 HTTP/1.1 tcp{client}: 0x5572399f30e8
2023-01-18 18:29:57.979 luup.variable_set:: 20380.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 22 now: 21 #hooks:0
Any thoughts?
Cheers
C
Virtual HTTP Devices plug-in:
I wanted to try this out. Installed the plugin and created one device, which came up as a light bulb. So far so good. In AltUI I clicked on the On/Off slider on the page. The log shows that the Target is set to one. Likewise for the Variable list in AltUI. However the Status never gets set to one and the light bulb icon doesn't go yellow.
In some plugins you set the Target and then the plugin checks the physical device actually went on by checking an actual status report from the device, which can be used to set the variable Status.
In other cases a plugin will send a message to the physical device but that device will have no status feedback mechanism available. So the Status variable has to be set locally when the Target is set and everybody hopes the physical device all worked.
Not to sure what Virtual HTTP Devices plug-in does in this regard? Does the above go in anyway to explaining what I'm seeing? Is the plugin looking for status feedback?
I have a couple of issue with Openluup ATM. I'm going to work through them in the order that they appeared if that's OK
OpenLuup on bare metal (Debian Bullseye) running Z-way server and Z-wave.me
Issue:
I deleted a (I think) virtual switch in OpenLuup
Now when I call up all devices I have this in a 'tile'
Error displaying device 0-20510 - urn:schemas-upnp-org:device:BinaryLight:1
nil is not defined
And below (in room 101)
ReferenceError: nil is not defined
at eval (eval at evaluateConditions (http://192.168.70.249:3480/J_ALTUI_verabox.js:960:18), :1:1)
at Object.evaluateConditions (J_ALTUI_verabox.js:960:18)
at Object._evaluateConditions [as evaluateConditions] (J_ALTUI_verabox.js:1642:37)
at Object._evaluateConditions [as evaluateConditions] (J_ALTUI_multibox.js:629:89)
at Object. (http://192.168.70.249:3480/J_ALTUI_uimgr.js:2572:23)
at Function.each (https://cdnjs.cloudflare.com/ajax/libs/jquery/3.5.1/jquery.min.js:2:2976)
at _getDeviceIconPath (http://192.168.70.249:3480/J_ALTUI_uimgr.js:2569:10)
at _deviceIconHtml (http://192.168.70.249:3480/J_ALTUI_uimgr.js:2739:18)
at _internalDeviceDraw (http://192.168.70.249:3480/J_ALTUI_uimgr.js:2765:19)
at _deviceDraw (http://192.168.70.249:3480/J_ALTUI_uimgr.js:2840:4)
Any ideas from anyone?
Full reboot has been done....
Cheers
C
I've been trying to figure out Reactor but I'm not very good at programming.
I have two scenes in VERA.
One scene should only run during the DAY and then stop running.
One scene should only run during the NIGHT and then stop running.
My scenes start off at the right times, but they do not turn off. I created a Sunrise/Sunset Reactor trigger and added it as a condition to each of my scenes.
However, the Reactor trigger when tripping or untripping does not prevent my Vera scenes from running. It will start them correctly the first day, but after that, both scene stay running and fight with each other. What am I doing wrong?
Thanks for any help!
If you are interested, here are the actions I wish to perform with each scene.
FARM STAND - DAY (runs at Sunrise)
Turn ON a device called LETTUCE LAMP
2a) Every 60 min, turn ON a device called LETTUCE PUMP
2b) Wait 15 min then turn OFF a device called LETTUCE PUMP
FARM STAND - NIGHT (runs at Sunset)
Turn OFF a device called LETTUCE LAMP
2a) Every 135 min, turn ON a device called LETTUCE PUMP
2b) Wait 15 min then turn OFF a device called LETTUCE PUMP
This sounds simple, but I cannot figure out how to disable these scenes when the theyre not supposed to run.
Good evening, all.
Is there a simple readme to set up and use a Broadlink device with OpenLuup?
The readme on github points to a thread on the old forum, and thence to a rabbit hole.
Is it just a case of adding IP address of the device? Or does it need the MAC?
Then how do I fire commands? It looks like I need to find the codes and send via Lua?
TIA
C
Hi Patrick,
A quick question about your virtual sensor plugin. I saw that the child sensors rely on polling for sensor data updates. Was there a reason not to use a watch on the underlying (source) state variable as opposed to polling. I'm asking in the sense that I need a fairly rapid response to a rise in humidity, but am unsure how to set sensor polling without adding additional io drag to openLuup.
I currently use the state humidity variable directly in a reactor sensor (the data is captured via a bluetooth device with multiple humidity variables), however, these state humidity variables have a generated name making it difficult to determine what is what in group of approximately 10 state humidity variables. So a virtual sensor solves the naming problem, while creating some trigger delay due to polling.
Thx
@toggledbits
I have Reactor running under openLuup (which is running inside vwout's Docker container).
On the activities tab, it tells me I should update to a newer version of the device information database. When I go to the Tools tab, for a fraction of a second I can see the green "Update Device Info" button along with the Troubleshooting & Support and Device Spy sections. But after that fraction of a second, they disappear and I only see the Test Tools and Update Device Information Database sections, to just above where the Green button used to be.
I've tried this on both Edge and Firefox with the same behavior (with extensions both on and off).
Any suggestions?
Plugin Switchboard : Virtual Switch in VeraPlus not shown in Openluup
-
@toggledbits said in Plugin Switchboard : Virtual Switch in VeraPlus not shown in Openluup:
I noticed when I first starting using my new RPI4 that the SSH connection would have frequent pregnant pauses.
@toggledbits did you mean to post that reply under this topic? (Asking cuz I don't see its precedent)
@librasun said in Plugin Switchboard : Virtual Switch in VeraPlus not shown in Openluup:
@toggledbits did you mean to post that reply under this topic? (Asking cuz I don't see its precedent)
Precedent was this post in topic: https://smarthome.community/post/5129
-
I changed the connection to ethernet but the problem is not resolved. It takes sometimes over 60 minutes or even more to reconnect with openluup or alui via IP; 3480. I have ordered a new micro DS card and I restore my RP4 backup. I hope the problem may be solved.
The strange thing is that node red server can be reached when openluup is not available.
-
Just out of curiosity, can you check if you are able to access the openLuup console? "http://IP:3480/openLuup"
That way you know whether it is openLuup or ALTUI which is causing the problem. ALTUI relies on a lot of stuff in the web if you don't localize the cdn and sometimes can cause some problems. I understand the need for the license check but for everything else, it seems silly to me so I have been localizing everything I could. -
This section of the latest log you sent is particularly worrying...
2021-03-08 19:10:48.819 luup.variable_set:: 28.urn:honeywell-com:serviceId:ThermostatData1.OutdoorHumidity was: now: #hooks:0 2021-03-08 19:10:48.819 luup.variable_set:: 28.urn:honeywell-com:serviceId:ThermostatData1.IndoorHumidity was: now: #hooks:0 2021-03-08 19:26:28.221 luup.variable_set:: 23.urn:joeyd-com:serviceId:HoneywellTCC1.t.6.refreshStatus was: now: #hooks:0 2021-03-08 19:26:28.222 luup.variable_set:: 23.urn:joeyd-com:serviceId:HoneywellTCC1.statusRefreshDateTime was: Mon, Mar 08, 07:10:48 PM now: Mon, Mar 08, 07:26:28 PM #hooks:0 2021-03-08 19:26:28.222 luup.variable_set:: 23.urn:joeyd-com:serviceId:HoneywellTCC1.getStatus was: Successful now: Unsuccessful. Error code: 5 #hooks:0 2021-03-08 19:26:28.222 luup.variable_set:: 23.urn:joeyd-com:serviceId:HoneywellTCC1.t.6.refreshStatus was: now: FAIL: Mon, Mar 08, 07:26 PM #hooks:0 2021-03-08 19:43:47.581 luup.variable_set:: 23.urn:joeyd-com:serviceId:HoneywellTCC1.t.7.refreshStatus was: now: #hooks:0 2021-03-08 19:43:47.582 luup.variable_set:: 23.urn:joeyd-com:serviceId:HoneywellTCC1.statusRefreshDateTime was: Mon, Mar 08, 07:26:28 PM now: Mon, Mar 08, 07:43:47 PM #Not one, but TWO, 15+ minute discontinuities, which Reactor spots has happened...
2021-03-08 19:46:05.991 luup_log:6: Reactor: ***** SYSTEM CLOCK HAS LEAPT FORWARDS! Last master tick 1615226880(2021-03-08.19:08:00), now 1615229165(2021-03-08.19:46:05)???I cannot think what might cause this, other than some event external to the system.
I do note, however, that your Honeywell devices are very, very chatty in the logs. Is that normal? Also, what might
Error code: 5mean? -
@toggledbits @akbooer
This evening I restore my backup (image) on my RP4, but the problem was not solved yet! I checked what I had edit last week. Last week I was playing a bit with switchboard. I installed this plugin on both machines (vera and openluup). On my vera I had created two virtual switches. The Switchboard plugin on both machines (Vera and Openluup) caused problem. After removing switchboard on openluup everything runs like a charm again !! -
It would be really helpful if I could get a log file from you which might highlight the problem. I've not come across this difficulty myself, nor (yet) had any other reports. Has anything else changed in your system?
Does the system remain up sufficiently long for you to get the logs and also revert? You can revert to any version manually by retrieving the files in the openLuup folder from the openLuup project in GitHub:
History for openLuup - akbooer/openLuup
a pure-Lua open-source emulation of the Vera Luup environment - History for openLuup - akbooer/openLuup
I've fallen out of the habit of tagging releases, so there's not a sufficiently recent one that you can revert to automatically.
I really would like to get to the root of this problem, though, rather than just trying to avoid it.
-
It looks like the problem has been resolved. It turned out to be the Honeywell plugin that caused problems. Honeywell's server was unreachable. Honeywell plugin on google home did not work either. Now everything works perfectly . Thanks everyone for the help
