The RemotePort change to :3480 was enogh for the device loading from vera, but was not enough for the GetVeraFiles.
For the GetVeraFiles working it needed the auth switch off in vera, because of this code in GetVeraFiles : http://192.168.1.2/directory.txt
D
dmon
@dmon
at _ClientAPI._commandTimeout (http://192.168.1.100:8111/client/ClientAPI.js:807:179
Seeing this randomly when returning to open browser tab after being away awhile. Once, maybe twice a day.
"What did you do to trigger it?" Literally nothing, just walked away and returned and there it was.
Actions taken in reasonably close proximity to this particular instance of it popping up: I'd restarted the MSR container in Portainer.
I'll try to grab some logs here shortly.
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.
Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions;
Fix an error in OWMWeatherController that could cause it to stop updating;
Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later;
Improve error detail in messages for EzloController during auth phase;
Add isRuleSet() and isRuleEnabled() functions to expressions extensions;
Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases);
Fix a place in the UI where 24-hour time was not being displayed.
This post does not apply to users of Intel/AMD-based systems. If you are using a Reactor image tagged latest-amd64 or stable-amd64, then this post does not apply to you. It also does not apply to bare-metal installs; it's for users of docker images on ARM-based systems only (principally Raspberry Pi hosts, but could be others).
After January 15, 2026, I will no longer produce the aarch64-tagged docker image for Reactor. The ARM images will be arm64 for 64-bit operating systems, and armv7l for 32-bit operating systems.
For those of you running a container from the aarch64 image today, this will be a relatively simple change: you just need to switch the image used for your docker container to a differently-tagged image. If you are using docker-compose, then this is a relatively simple matter of changing the image line in your docker-compose.yaml file and then stopping (docker-compose down) and restarting (docker-compose up -d) your Reactor daemon.
But there's a catch... not all of you can safely just switch from the aarch64 image to the arm64 image. And, you can't just trust the output of uname -m, for example, because this exposes the CPU architecture, but not the word size of the OS running on that CPU.
For Raspberry Pi systems, the transition to 64-bit operating systems was long (starting in 2016) and not always obvious — although there was a first "official" 64-bit OS for RPis in 2020, it did not become a default recommendation in the Raspberry Pi Imager until 2021, and then that was only the default for Pi 3/4 systems with >4GB RAM; it was 2022 before it was universally recommended for all 64-bit CPUs regardless of RAM size. Depending on when you first imaged your RPi system and what default you may have been offered/chosen, you could today easily have a 64-bit CPU Raspberry Pi running a 32-bit version of the operating system. Upgrades along the way would not change this; changing it to fully 64-bit requires a full reimage of the system.
To establish if your OS is 64- or 32-bit, log in to your Pi and run: sudo dpkg-architecture -q DEB_HOST_ARCH. If the response is arm64 or aarch64, then you are running a 64-bit OS and you should use the arm64-tagged image. If it's anything else, you are running a 32-bit OS, and you should use the armv7l-tagged image.
pi@rpi4-1:~ $ sudo dpkg-architecture -q DEB_HOST_ARCH
armhf
pi@rpi4-1:~ $ uname -m
aarch64
pi@rpi4-1:~ $
In the example above, the uname command reports that the CPU is 64-bit architecture (aarch64), which is true for the host on which I ran these commands, but the DEB_HOST_ARCH value is armhf, indicating a 32-bit operating system. This system has to use the armv7l-tagged image.
Other systems will have their own ways of determining the word size of the running OS. Since the majority of Reactor users running ARM systems are on Raspberry Pis, I am able to supply the above instructions, but if you happen to have a different ARM system, you'll need to do some web searching to figure out how to expose that information. Or, you can just try the arm64 image, and if it doesn't start up, try the armv7l image.
Remember to always back up your system before making any changes.
For everyone, please make this change as soon as possible, and if you have any trouble finding a working image, please (1) go back to the current aarch64 image; and (2) let me know in this thread along with as much detail about your host system as you can offer (including the output of the dpkg-architecture command mentioned above).
Hi,
I'm in the process of migrating from a Raspberry Pi 4 (ARMv7) to a Raspberry Pi 5 (ARMv8/aarch64), but I’ve run into an issue: there is no proper ARMv8/aarch64 image available.
None of the existing images run on the Pi 5 - they all exit immediately with code 139 (segmentation fault), which typically indicates that the binaries inside the image are not compatible with the ARM64/aarch64 architecture used by the Pi 5.
Would it be possible to publish a correct ARMv8/aarch64 (linux/arm64) image?
Building one should be relatively straightforward using docker buildx with multi-arch support. For example, my own Node.js images are built this way:
docker buildx build --push \
-t <localrepo>/<project>:<tag> \
--platform=linux/arm64,linux/amd64 \
--file ./apps/<project>/Dockerfile .
This produces both the AMD64 and ARM64/v8 variants automatically.
Also, as a side note, it may be best to avoid using Alpine as the base image for the ARM64 build, since musl-based builds often cause compatibility issues and unnecessary headaches. A glibc-based base image (e.g., Debian or Ubuntu) tends to work far more reliably on ARM64, especially for Node.js applications.
@toggledbits - tagging you in case you missed this.
Thanks,
mgvra
Sorry to write here without trying, but I’m flying today.
Am I correct if i say that script action with alarm() makes it possible to execute a reaction in a given interval, lets say 15 seconds or 3.5 minutes?
That sounds amazing, since I’ve used weird tricks, including a custom controller, just to do this.
Just throwing out a general hint to the people running Homebridge and MQTT.
Homebridge MQTT-Thing hasn't been updated in almost 2 years and it falls behind on compatibility with the development of Homebridge.
I was looking for a replacement and found Homebridge Easy MQTT and I think it's a good replacement for MQTT-Thing. I particularly find Easy MQTT Value tranformers easier to to understand and use compared to MQTT-Thing Apply function.
It took a while to migrate everything but I'm pleased and can recommend.
@toggledbits Do you know if this is related to that PR or is it a change they made in 2025.11.1?
[latest-25310]2025-11-11T13:16:24.319Z <HassController:INFO> HassController#hass perform x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_dag with { "time": "10:45" }
[latest-25310]2025-11-11T13:16:24.320Z <HassController:INFO> HassController#hass: sending payload for x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_dag action: { "type": "call_service", "service_data": { "date": (null), "time": "10:45", "datetime": (null), "timestamp": (null) }, "domain": "input_datetime", "service": "set_datetime", "target": { "entity_id": "input_datetime.vvb_dag" } }
[latest-25310]2025-11-11T13:16:24.321Z <HassController:ERR> HassController#hass request 1762866984320<2025-11-11 14:16:24> (call_service) failed: [Error] Not a parseable type for dictionary value @ data['date'] [-]
[latest-25310]2025-11-11T13:16:24.321Z <HassController:WARN> HassController#hass action x_hass_input_datetime.set_datetime({ "time": "10:45" }) on Entity#hass>input_datetime_vvb_dag failed!
[latest-25310]2025-11-11T13:16:24.321Z <HassController:INFO> Service call payload:
{"type":"call_service","service_data":{"date":null,"time":"10:45","datetime":null,"timestamp":null},"domain":"input_datetime","service":"set_datetime","target":{"entity_id":"input_datetime.vvb_dag"},"id":1762866984320}
[latest-25310]2025-11-11T13:16:24.322Z <HassController:INFO> Service data:
{"fields":{"date":{"example":"\"2019-04-20\"","selector":{"text":{"multiline":false,"multiple":false}}},"time":{"example":"\"05:04:20\"","selector":{"time":{}}},"datetime":{"example":"\"2019-04-20 05:04:20\"","selector":{"text":{"multiline":false,"multiple":false}}},"timestamp":{"selector":{"number":{"min":0,"max":9223372036854776000,"mode":"box","step":1}}}},"target":{"entity":[{"domain":["input_datetime"]}]}}
[latest-25310]2025-11-11T13:16:24.322Z <Engine:ERR> Engine#1 reaction rule-mgb8pfhs:S step 0 perform x_hass_input_datetime.set_datetime failed: [Error] Not a parseable type for dictionary value @ data['date'] [-]
[latest-25310]2025-11-11T13:16:24.322Z <Engine:INFO> Engine#1 action args: { "time": "10:45" }
[latest-25310]2025-11-11T13:16:24.322Z <Engine:INFO> Resuming reaction Sätt Schema VVB i Home Assistant<AKTIV> (rule-mgb8pfhs:S) from step 1
[latest-25310]2025-11-11T13:16:24.323Z <HassController:INFO> HassController#hass perform x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_natt with { "time": "03:00", "timestamp": 0 }
[latest-25310]2025-11-11T13:16:24.323Z <HassController:INFO> HassController#hass: sending payload for x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_natt action: { "type": "call_service", "service_data": { "date": (null), "time": "03:00", "datetime": (null), "timestamp": 0 }, "domain": "input_datetime", "service": "set_datetime", "target": { "entity_id": "input_datetime.vvb_natt" } }
[latest-25310]2025-11-11T13:16:24.324Z <HassController:ERR> HassController#hass request 1762866984323<2025-11-11 14:16:24> (call_service) failed: [Error] Not a parseable type for dictionary value @ data['date'] [-]
[latest-25310]2025-11-11T13:16:24.324Z <HassController:WARN> HassController#hass action x_hass_input_datetime.set_datetime({ "time": "03:00", "timestamp": 0 }) on Entity#hass>input_datetime_vvb_natt failed!
[latest-25310]2025-11-11T13:16:24.324Z <HassController:INFO> Service call payload:
{"type":"call_service","service_data":{"date":null,"time":"03:00","datetime":null,"timestamp":0},"domain":"input_datetime","service":"set_datetime","target":{"entity_id":"input_datetime.vvb_natt"},"id":1762866984323}
[latest-25310]2025-11-11T13:16:24.324Z <HassController:INFO> Service data:
{"fields":{"date":{"example":"\"2019-04-20\"","selector":{"text":{"multiline":false,"multiple":false}}},"time":{"example":"\"05:04:20\"","selector":{"time":{}}},"datetime":{"example":"\"2019-04-20 05:04:20\"","selector":{"text":{"multiline":false,"multiple":false}}},"timestamp":{"selector":{"number":{"min":0,"max":9223372036854776000,"mode":"box","step":1}}}},"target":{"entity":[{"domain":["input_datetime"]}]}}
[latest-25310]2025-11-11T13:16:24.324Z <Engine:ERR> Engine#1 reaction rule-mgb8pfhs:S step 1 perform x_hass_input_datetime.set_datetime failed: [Error] Not a parseable type for dictionary value @ data['date'] [-]
[latest-25310]2025-11-11T13:16:24.324Z <Engine:INFO> Engine#1 action args: { "time": "03:00", "timestamp": 0 }
[latest-25310]2025-11-11T13:16:24.325Z <Engine:INFO> Resuming reaction Sätt Schema VVB i Home Assistant<AKTIV> (rule-mgb8pfhs:S) from step 2
[latest-25310]2025-11-11T13:16:24.325Z <Engine:INFO> Sätt Schema VVB i Home Assistant<AKTIV> all actions completed.
Hello,
I currently have an office light (connected via a Leviton Zwave Dimmer switch) controlled from a Gen5 Aeotech Zwave switch installed on my Synology 720+ NAS. I run HA(2025.11.10) in a virtual machine from my NAS and Reactor on the container manager of the same NAS. Prior to updating to 25304 the rule I had set to turn the light on to a specific dimming value worked correctly. Now the rule appears to follow the decision tree, however the reaction does not trigger setting the dimming or turning on the office light?
Strangely I can still turn the light on and off as well as dim it directly from HASS..? I have tried using the ''try this action'' button in the rules reaction setting and it will not control the light and does not throw an error flagÉ
Please help,
P.S
Reactor has been rock steady for me over the last few years and I'm a big fan of this solution.
I don't know if you guys are into dashboards, but I am.
For a second home I tried the Shelly Wall Display 2, and while not so big, it worked well over the summer.
Since we're remodeling our house, I just swapped my old Fire Tablet (with its own problems) with two new Shelly Wall Display XL. I just removed the standard firmware, and I added mine (https://github.com/dbochicchio/ShellyElevate), forked from https://github.com/RapierXbox/ShellyElevate
I just managed to support buttons (this thing has 4 of them) and it's all auto-discovered by Home Assistant and accessible via Reactor.
I also have a new build in the works with support for buttons inside HA.
I added a bonus Javascript interface sending events (screen/screensaver status, buttons, motion) to automatically drive the dashboard (all doing in HTML+Javascript and monitoring Reactor's variable).
This specifical thing excluded, go get one of them, the device has a decent CPU for HA dashboards and blends wonderfully in the decor.
Posts
-
Openluup - verabridge can not load devices. -
Openluup - verabridge can not load devices.I've found this old forum post with similar problem (except I have no slave vera, only one) : verabridge-credentials
So I edited the two mentioned file in vera with ssh (/etc/lighttpd/lighttpd.conf, /etc/lighttpd.conf) and commented out the “mod_auth” section.
I've reinstalled freshly the VeraBrdige plugin.
Everything worked fine, the devices has been loadaded, and the GetVeraFiles donwloaded the needed files from the Vera.After this I changed back the “mod_auth” section in the two files. Now the auth is enabled again.
I had to changed the RemotePort to :3840 at Variables.
Now it seems working.
I really don't know why my vera needs auth if you mentioned that your vera doesn't need it from OpenLuup. -
Openluup - verabridge can not load devices.device attributes page :
I am very new here and can't find how can I send PM in this forum (I am not sure is it even possible in NodeBB engine), the forum can not allow me to attach files to my post yet.
I am not sure whether the log contains any sensitive info so I attached a link for the logs and send you the password in chat for the file.
log files : linkAfter it did not worked as I wrote here yestersay I had a (maybe stupid) try to change the L_VerBridge.lua to use ":3840" string instead of "/port_3480" . I've changed RemotPort variable and the remote_request function. After the changes it downloaded the devices, but got another errors. You can see these at the end of the logs.
Now I copied back the original L_VerBridge.lua and got the original error atthe beginning of teh log.This is why I asked how can I reinstall the VeraBridge plugin, to eliminate the mixing with my tries in the log files.
-
Openluup - verabridge can not load devices.Console Output: :
First output was :
"MD5 module not available for digest authorization: http://192.168.1.2/port_3480/data_request?id=user_data2&output_format=json&ns=1"
I'ves solved it with :
sudo apt-get -y install lua-md5Now the console output is :
"<?xml version="1.0" encoding="iso-8859-1"?>\010<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"\010 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\010<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">\010 <head>\010 <title>401 - Unauthorized</title>\010 </head>\010 <body>\010 <h1>401 - Unauthorized</h1>\010 </body>\010</html>\010<?xml version="1.0" encoding="iso-8859-1"?>\010<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"\010 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\010<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">\010 <head>\010 <title>400 - Bad Request</title>\010 </head>\010 <body>\010 <h1>400 - Bad Request</h1>\010 </body>\010</html>\010"
So it seems an auth problem.
Is there any possibilities to give the credentials to the VeraBridge plugin ?Strange that if I try this way (:3480 instead of /port_3480) it's working and get back everything:
http://192.168.1.2:3480/data_request?id=user_data2&output_format=json&ns=1What I try to bridge is a Vera Lite with UI5.
How can I reinstall the verabridge plugin from scratch ?
-
Openluup - verabridge can not load devices.Hello,
I have a fresh openluup install on a raspberry.
Just installed "Vera Bridge" plugin, but I can't make it to work.
The plugin can not load the device infos from the vera.
This is what I can see in the OpenLuup log :openLuup.client:: WGET error status: -1, request: http://192.168.1.2/port_3480/data_request?id=user_data2&output_format=json&ns=1
I have tried it from a console on the same raspberry this way :
wget http://192.168.1.2:3480/data_request?id=user_data2&output_format=json&ns=1
It worked, so I think it's not credential or network issue.What can be the solution for this ?
more openluup log :
408 lines, 1 error, max gap 61s @ 2022-08-12 20:51:01.568
2022-08-12 19:21:24.150 :: openLuup LOG ROTATION :: (runtime 0.0 days)
2022-08-12 19:21:24.154 openLuup.init:: init phase completed
2022-08-12 19:21:24.155 openLuup.io.server:: starting HTTP:3480 server on port: 3480 tcp{server}: 0x1c48ee8
2022-08-12 19:21:24.157 openLuup.io.server:: starting SMTP server on port: 2525 tcp{server}: 0x1b461d8
2022-08-12 19:21:24.158 openLuup.io.server:: starting POP3 server on port: 11011 tcp{server}: 0x1b48780
2022-08-12 19:21:24.158 openLuup.historian:: starting data historian
2022-08-12 19:21:24.159 openLuup.historian:: using memory cache size (per-variable): 1024
2022-08-12 19:21:24.168 openLuup.scheduler:: starting
2022-08-12 19:21:24.169 openLuup.scheduler:: [2] openLuup device startup
2022-08-12 19:21:24.170 luup_log:2: v22.7.31
2022-08-12 19:21:24.171 luup_log:2: sync in 35.8 s
2022-08-12 19:21:24.190 luup.variable_watch:: callback=housemode_watcher, watching=2.openLuup.HouseMode
2022-08-12 19:21:24.191 luup.register_handler:: global_function_name=openLuup_email, request=openLuup@openLuup.local
2022-08-12 19:21:24.191 luup.register_handler:: global_function_name=openLuup_images, request=images@openLuup.local
2022-08-12 19:21:24.192 luup.register_handler:: global_function_name=openLuup_events, request=events@openLuup.local
2022-08-12 19:21:24.192 luup.register_handler:: global_function_name=openLuup_mailbox, request=mail@openLuup.local
2022-08-12 19:21:24.193 luup.chdev.append:: [AltAppStore] Alternate App Store
2022-08-12 19:21:24.193 luup.chdev.sync:: [2] openLuup, syncing children
2022-08-12 19:21:24.194 luup_log:2: starting MQTT $SYS/broker statistics
2022-08-12 19:21:24.196 luup_log:2: 3Mb, 2.1%cpu, 0.0days
2022-08-12 19:21:24.211 openLuup.scheduler:: [2] openLuup device startup completed: status=true, msg=sync in 35.8 s, name=L_openLuup
2022-08-12 19:21:24.212 openLuup.scheduler:: [3] Alternate UI device startup
2022-08-12 19:21:24.212 luup_log:3: ALTUI: initstatus(3) starting version: v2.54
2022-08-12 19:21:24.214 openLuup.scheduler:: [3] Alternate UI device startup completed: status=, msg=, name=
2022-08-12 19:21:24.214 openLuup.scheduler:: [7] VeraBridge device startup
2022-08-12 19:21:24.215 luup_log:7: VeraBridge
2022-08-12 19:21:24.215 luup_log:7: 2021.01.03
2022-08-12 19:21:24.216 luup_log:7: 192.168.1.2
2022-08-12 19:21:24.216 luup_log:7: device clone numbering starts at 10000
2022-08-12 19:21:24.217 luup_log:7: VeraBridge maps remote Zwave controller
2022-08-12 19:21:24.218 luup_log:7: v21.1.3
2022-08-12 19:21:24.242 openLuup.client:: WGET error status: -1, request: http://192.168.1.2/port_3480/data_request?id=user_data2&output_format=json&ns=1
2022-08-12 19:21:24.242 luup.set_failure:: status = 2
2022-08-12 19:21:24.243 luup.variable_set:: 7.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 2 now: 2 #hooks:0
2022-08-12 19:21:24.244 luup.variable_set:: 7.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 1660323316 now: 1660324884 #hooks:0
2022-08-12 19:21:24.246 luup_log:7: registering with AltUI [3] as Data Storage Provider
2022-08-12 19:21:24.247 luup.register_handler:: global_function_name=HTTP_VeraBridgeMirror_192.168.1.2, request=HTTP_VeraBridgeMirror_192.168.1.2
2022-08-12 19:21:24.249 luup.call_action:: 3.urn:upnp-org:serviceId:altui1.RegisterDataProvider
2022-08-12 19:21:24.260 openLuup.scheduler:: [7] VeraBridge device startup completed: status=, msg=No Vera, name=VeraBridge
2022-08-12 19:21:24.261 openLuup.scheduler:: [4] Alternate App Store device startup
2022-08-12 19:21:24.261 luup_log:4: AltAppStore : starting...
2022-08-12 19:21:24.262 luup.variable_set:: 4.urn:upnp-org:serviceId:altui1.DisplayLine1 was: AltAppStore now: AltAppStore #hooks:0
2022-08-12 19:21:24.263 luup.variable_set:: 4.urn:upnp-org:serviceId:altui1.DisplayLine2 was: now: #hooks:0
2022-08-12 19:21:24.264 luup_log:4: AltAppStore : v20.3.30
2022-08-12 19:21:24.264 luup.set_failure:: status = 0
2022-08-12 19:21:24.265 luup.variable_set:: 4.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.266 luup.variable_set:: 4.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.267 openLuup.scheduler:: [4] Alternate App Store device startup completed: status=true, msg=OK, name=AltAppStore
2022-08-12 19:21:24.268 openLuup.scheduler:: [5] Harmony Hub Control device startup
2022-08-12 19:21:24.280 luup.variable_set:: 5.urn:rboer-com:serviceId:Harmony1.LinkStatus was: Ok now: Starting... #hooks:0
2022-08-12 19:21:24.281 luup.variable_set:: 5.urn:rboer-com:serviceId:Harmony1.IconSet was: 0 now: 3 #hooks:0
2022-08-12 19:21:24.282 luup.attr_set:: 5.altid = HAM5_CNTRL
2022-08-12 19:21:24.326 luup.set_failure:: status = 0
2022-08-12 19:21:24.326 luup.variable_set:: 5.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.327 luup.variable_set:: 5.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.328 openLuup.scheduler:: [5] Harmony Hub Control device startup completed: status=true, msg=OK, name=Harmony Control
2022-08-12 19:21:24.332 luup_log:3: ALTUI: UPNPregisterDataProvider(3,Vera@192.168.1.2,http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_192.168.1.2,[{
"default":"device.serviceId.name",
"key":"mirror",
"label":"Mirror",
"type":"text"
}])
2022-08-12 19:21:24.337 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... now: {"Vera@192.168.1.2":{"url":"http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_192.168.1.2","callback":... #hooks:0
2022-08-12 19:21:24.360 openLuup.io.server:: HTTP:3480 connection from 192.168.1.24 tcp{client}: 0x1d21868
2022-08-12 19:21:24.363 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=323312852&Timeout=60&MinimumDelay=1500&=1660323303557 HTTP/1.1 tcp{client}: 0x1d21868
2022-08-12 19:21:24.646 openLuup.server:: request completed (34267 bytes, 3 chunks, 280 ms) tcp{client}: 0x1d21868
2022-08-12 19:21:24.648 openLuup.io.server:: HTTP:3480 connection from 192.168.1.24 tcp{client}: 0x1d6a9b0
2022-08-12 19:21:24.661 openLuup.server:: GET /data_request?id=user_data&output_format=json&DataVersion=323312340&=1660323303558 HTTP/1.1 tcp{client}: 0x1d21868
2022-08-12 19:21:25.252 openLuup.server:: request completed (70135 bytes, 5 chunks, 588 ms) tcp{client}: 0x1d21868
2022-08-12 19:21:25.253 luup_log:3: ALTUI: startupDeferred, called on behalf of device:3
2022-08-12 19:21:25.338 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.Version was: v2.54 now: v2.54 #hooks:0
2022-08-12 19:21:25.934 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"Vera@192.168.1.2":{"url":"http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_192.168.1.2","callback":... now: {"thingspeak":{"url":"","callback":"sendValueToStorage_thingspeak","parameters":[{"type":"number","key":"channelid"... #hooks:0
2022-08-12 19:21:25.964 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"thingspeak":{"url":"","callback":"sendValueToStorage_thingspeak","parameters":[{"type":"number","key":"channelid"... now: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... #hooks:0
2022-08-12 19:21:25.996 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... now: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... #hooks:0
2022-08-12 19:21:25.999 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.VariablesToSend was: now: #hooks:0
2022-08-12 19:21:26.009 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.RemoteVariablesToWatch was: now: #hooks:0
2022-08-12 19:21:26.010 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.VariablesToWatch was: now: #hooks:0
2022-08-12 19:21:26.012 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.Timers was: [] now: [] #hooks:0
2022-08-12 19:21:26.013 luup_log:3: ALTUI: Wkflow - enableWorkflows(3,0,0)Thank You.
d.