Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Unsolved
Collapse
Discussion Forum to share and further the development of home control and automation, independent of platforms.
  1. Home
  2. Software
  3. Multi-System Reactor
  4. Vera reload detected where there does not appear to be one.
Copying a global reaction
tunnusT
With build 25328, if you copy a global reaction, a new reaction does not appear in the UI unless you do a refresh. I recall this used to work without needing this page refresh? Anyway, only a minor nuisance.
Multi-System Reactor
[Reactor] Bug when sending MQTT boolean payloads
therealdbT
Topic thumbnail image
Multi-System Reactor
Difficulty defining repeating annual period
R
I have tried numerous ways to define a recurring annual period, for example from December 15 to January 15. No matter which method I try - after and before, between, after and/not after, Reactor reports "waiting for invalid date, invalid date. Some constructs also seem to cause Reactor to hang, timeout and restart. For example "before January 15 is evaluated as true, but reports "waiting for invalid date, invalid date". Does anyone have a tried and true method to define a recurring annual period? I think the "between" that I used successfully in the past may have broken with one of the updates.
Multi-System Reactor
Need help with sequence
T
Good evening all, For about the past week or so, I've been having problems with a specific rule in my home automation that controls when my home goes from an Away mode to Home mode. One of the conditions it checked for was my alarm panel, when it changed from Armed Away to Disarmed. There seems to have been a firmware update on the panel that added an intermittent step of "pending", and I can't say for certain it happens 100% of the time. Is there a way to write a condition that so it changes from one condition, to the next, and then another condition? As in, Home alarm changes from armed_away to pending to disarmed. Thanks.
Multi-System Reactor
Possible feature request?
CatmanV2C
No idea how easy this would be. During my migration away from Z-wave I've been replacing the Z-wave devices with Sonoff which has broken some of my automations. Any chance of a 'Test Reaction' function to call out which ones are broken because an entity no longer exists? Without actually running the reaction? Or does this exist already and I'm just not aware of how to do it? Obviously I can see entities that are no longer available, but not quite what I'm looking for. I guess it's something of an edge case so no huge issue. TIA! C
Multi-System Reactor
Logic Assistance: Exterior Lights on when Illuminance Below Threshold
PablaP
Topic thumbnail image
Multi-System Reactor
Time series documentation
tunnusT
Is the current manual (incl. examples) up to date with how retention value is handled in time series configuration? Referring to this post
Multi-System Reactor
MQTT templates for ZIgbee scene controller, or a better way?
CatmanV2C
Topic thumbnail image
Multi-System Reactor
Reset a delay
CatmanV2C
I'm sure this has been asked, and answered, but damned if I can figure it out Use case: I have a rear garden with lights. A door from the kitchen into the garden and a door from the garage. Currently if I open the kitchen door the lights come on (yay) and a 3 minute delay starts. After 3 minutes, no matter what else happens, the lights go off (Boo! But also yay!) What I would like is for the 3 minute delay until the lights go off to start from the latest door open event. That is, if I'm going from kitchen to garage, and back again, the lights stay on until there's three minutes of no activity. I've tried 'hacking' with a virtual switch, but can't seem to stop the delay. Any pointers? TIA C
Multi-System Reactor
Reactor Loading Screen Safari
S
Topic thumbnail image
Multi-System Reactor
Constraints states visually do not match actual
S
Topic thumbnail image
Multi-System Reactor
[MSR] Feature request: For Each action on arrays/groups
therealdbT
Topic thumbnail image
Multi-System Reactor
[Solved] Error: Command timeout
G
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.
Multi-System Reactor
Issue with MSR UI becoming unresponsive
S
I'm having an issue with MSR's UI being very unresponsive. It started happening a couple days ago and I didn't make any changes that would have caused this except adding some meross lan devices in HA. When I go into an entity action and use the search functionality, it usually will start filtering and then get to a place after a few letters are entered where it will take 30 seconds or more (sometimes minutes) for the UI to show what I am typing. During this time MSR ui is completely unresponsive. I've tried multiple browsers and multiple computers. HA and MSR are both deployed in docker. I have run HTOP on the host and when the problem happens there are no CPU/Memory spikes at all. From a functionality standpoint MSR is working perfectly. This seems to be an UI issue only. Do i need to ditch Docker and run MSR on a Proxmox VM? I have both stand alone Docker and Proxmox environments. I dont mind doing that I just want to be able to use the UI again... Installation method Home Assistant Container Core 2025.7.3 Frontend 20250702.3 nothing crazy in the logs except some openweather map stuff that doesn't make any sense as it is working fine in MSR Any help would be greatly appreciated Reactor latest-25328-b2ed1365 app 25328 configuration from /var/reactor/config NODE_PATH /opt/reactor:/opt/reactor/node_modules [latest-25328]2025-11-30T20:01:53.843Z <app:null> Reactor build latest-25328-b2ed1365 starting on v24.11.1 /usr/local/bin/node [latest-25328]2025-11-30T20:01:53.844Z <app:null> Process ID 1 user/group 0/0; docker; platform linux/x64 #161-Ubuntu SMP Tue Jul 22 14:25:40 UTC 2025; locale (undefined) [latest-25328]2025-11-30T20:01:53.844Z <app:null> Basedir /opt/reactor; data in /var/reactor/storage [latest-25328]2025-11-30T20:01:53.844Z <app:null> NODE_PATH=/opt/reactor:/opt/reactor/node_modules [latest-25328]2025-11-30T20:01:53.865Z <app:null> Resolved timezone=America/New_York, environment TZ=America/New_York; offset minutes from UTC=-300 [latest-25328]2025-11-30T20:01:53.867Z <default:null> Module i18n v25141 [latest-25328]2025-11-30T20:01:53.867Z <app:null> Configured locale (undefined); selected locale(s) en-US.UTF-8 [latest-25328]2025-11-30T20:01:53.879Z <app:null> Loaded locale en-US for en-US [latest-25328]2025-11-30T20:01:53.879Z <app:null> Local date/time using configured timezone and locale formatting is "11/30/2025, 3:01:53 PM" [latest-25328]2025-11-30T20:01:53.889Z <Structure:null> Module Structure v25326 [latest-25328]2025-11-30T20:01:53.890Z <Capabilities:null> Module Capabilities v24312 [latest-25328]2025-11-30T20:01:53.904Z <Plugin:null> Module Plugin v25141 [latest-25328]2025-11-30T20:01:53.923Z <Timer:null> Module Timer v25279 [latest-25328]2025-11-30T20:01:53.924Z <TimerBroker:null> Module TimerBroker v25314 [latest-25328]2025-11-30T20:01:53.927Z <Entity:null> Module Entity v25251 [latest-25328]2025-11-30T20:01:53.929Z <Controller:null> Module Controller v25253 [latest-25328]2025-11-30T20:01:53.930Z <AlertManager:null> Module AlertManager v25318 [latest-25328]2025-11-30T20:01:53.937Z <default:null> Module Ruleset v25283 [latest-25328]2025-11-30T20:01:53.937Z <default:null> Module Rulesets v25141 [latest-25328]2025-11-30T20:01:53.942Z <GlobalExpression:null> Module GlobalExpression v25258 [latest-25328]2025-11-30T20:01:53.953Z <Predicate:null> Module Predicate v25328 [latest-25328]2025-11-30T20:01:53.956Z <Rule:null> Module Rule v25323 [latest-25328]2025-11-30T20:01:53.958Z <GlobalReaction:null> Module GlobalReaction v25292 [latest-25328]2025-11-30T20:01:53.959Z <Engine:null> Module Engine v25325 [latest-25328]2025-11-30T20:01:53.964Z <httpapi:null> Module httpapi v25328 [latest-25328]2025-11-30T20:01:53.972Z <wsapi:null> Module wsapi v25328 [latest-25328]2025-11-30T20:01:53.994Z <TaskQueue:null> Module TaskQueue 24138 [latest-25328]2025-11-30T20:01:53.994Z <VeraController:null> Module VeraController v25141 [latest-25328]2025-11-30T20:01:54.179Z <HassController:null> Module HassController v25325 [latest-25328]2025-11-30T20:02:13.797Z <OWMWeatherController:null> Module OWMWeatherController v25268 [latest-25328]2025-11-30T20:02:13.800Z <SystemController:null> Module SystemController v25323 [latest-25328]2025-11-30T20:02:13.807Z <MQTTController:null> Module MQTTController v22092 [latest-25328]2025-11-30T20:02:20.630Z <OWMWeatherController:CRIT> FetchError: request to https://api.openweathermap.org/data/2.5/weather?lat=xxxxxxxxxx&lon=-xxxxxxxxx&appid=xxxxxxxxxxxxxxxxxxxxxxxxxx&units=standard&_r=1xxxxxxxxxxxxxxfailed, reason: [-] FetchError: request to https://api.openweathermap.org/data/2.5/weather?lat=xxxxxxxxxxx&lon=-xxxxxxxxxxxxxxxxxx&appid=xxxxxxxxxxxxxxxxxxx&units=standard&_r=xxxxxxxxxxxxxxxfailed, reason: at ClientRequest.<anonymous> (/opt/reactor/node_modules/node-fetch/lib/index.js:1501:11) at ClientRequest.emit (node:events:508:28) at ClientRequest.emit (node:domain:489:12) at emitErrorEvent (node:_http_client:108:11) at TLSSocket.socketErrorListener (node:_http_client:575:5) at TLSSocket.emit (node:events:508:28) at TLSSocket.emit (node:domain:489:12) at emitErrorNT (node:internal/streams/destroy:170:8) at emitErrorCloseNT (node:internal/streams/destroy:129:3) at processTicksAndRejections (node:internal/process/task_queues:89:21
Multi-System Reactor
Date/time condition
tunnusT
Topic thumbnail image
Multi-System Reactor
Device log?
G
@toggledbits is there a log that will show me what rule is turning on a specific device? I've got a switch that has been kicking on at 2200 ET for several nights now and the reactor.log doesn't have a thing in it that I can see on a device level (it being more rules-based).
Multi-System Reactor
Midnight crossing not working in date/time condition (build 25325)
tunnusT
Topic thumbnail image
Multi-System Reactor
Reactor (Multi-System/Multi-Hub) Announcements
toggledbitsT
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.
Multi-System Reactor
[Solved] Local expression in Rule does not evaluate as they used to do
CrilleC
Topic thumbnail image
Multi-System Reactor
Home Assistant 2025.11.2 and latest-25315
CrilleC
Topic thumbnail image
Multi-System Reactor

Vera reload detected where there does not appear to be one.

Scheduled Pinned Locked Moved Multi-System Reactor
3 Posts 2 Posters 553 Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • CatmanV2C Offline
    CatmanV2C Offline
    CatmanV2
    wrote on last edited by CatmanV2
    #1

    I may have posted this in the wrong section. MSR running on Bare metal Debian bullseye. Both Openluup and MSR are on the same device (an Intel NUC) at IP 192.168.70.249. Any suggestions as to where I go to resolve?

    TIA

    Happy new year, everyone! Hope all are well!

    Looking for some pointers troubleshooting a slightly puzzling to me issue. When digging around on a different issue I noticed this happening regularly in the MSR logs:

    [latest-24366]2025-01-10T19:50:07.630Z <Engine:NOTICE> Starting reaction Garden lights on when the doors are open<SET> (rule-lb2h69nb:S)
    [latest-24366]2025-01-10T19:50:07.630Z <VeraController:INFO> VeraController#vera perform action power_switch.on on Switch#vera>device_20060 with [Object]{  }
    [latest-24366]2025-01-10T19:50:07.630Z <VeraController:INFO> VeraController#vera perform action power_switch.set on Switch#vera>device_20060 with [Object]{ "state": true }
    [latest-24366]2025-01-10T19:50:07.670Z <VeraController:NOTICE> VeraController#vera action power_switch.set([Object]{ "state": true }) on Switch#vera>device_20060 succeeded
    [latest-24366]2025-01-10T19:50:07.671Z <Engine:INFO> Resuming reaction Garden lights on when the doors are open<SET> (rule-lb2h69nb:S) from step 1
    [latest-24366]2025-01-10T19:50:07.672Z <Engine:NOTICE> Garden lights on when the doors are open<SET> delaying until 1736538787672<10/01/2025, 19:53:07>
    [latest-24366]2025-01-10T19:50:19.595Z <Rule:INFO> Garden lights on when the doors are open (rule-lb2h69nb in Outside Lights) evaluated; rule state transition from SET to RESET!
    [latest-24366]2025-01-10T19:52:16.506Z <Rule:INFO> Garden lights on when the doors are open (rule-lb2h69nb in Outside Lights) evaluated; rule state transition from RESET to SET!
    [latest-24366]2025-01-10T19:52:16.515Z <Engine:INFO> [Engine]Engine#1 not enqueueing rule-lb2h69nb:S: already in queue with status 2
    [latest-24366]2025-01-10T19:52:20.823Z <Rule:INFO> Garden lights on when the doors are open (rule-lb2h69nb in Outside Lights) evaluated; rule state transition from SET to RESET!
    [latest-24366]2025-01-10T19:53:07.676Z <Engine:INFO> Resuming reaction Garden lights on when the doors are open<SET> (rule-lb2h69nb:S) from step 2
    [latest-24366]2025-01-10T19:53:07.677Z <VeraController:INFO> VeraController#vera perform action power_switch.off on Switch#vera>device_20060 with [Object]{  }
    [latest-24366]2025-01-10T19:53:07.678Z <VeraController:INFO> VeraController#vera perform action power_switch.set on Switch#vera>device_20060 with [Object]{ "state": false }
    [latest-24366]2025-01-10T19:53:07.719Z <VeraController:NOTICE> VeraController#vera action power_switch.set([Object]{ "state": false }) on Switch#vera>device_20060 succeeded
    [latest-24366]2025-01-10T19:53:07.720Z <Engine:INFO> Resuming reaction Garden lights on when the doors are open<SET> (rule-lb2h69nb:S) from step 3
    [latest-24366]2025-01-10T19:53:07.721Z <Engine:INFO> Garden lights on when the doors are open<SET> all actions completed.
    [latest-24366]2025-01-10T19:55:04.468Z <VeraController:ERR> VeraController#vera update request failed: [FetchError] network timeout at: http://192.168.70.249:3480/data_request?id=status&Timeout=15&DataVersion=416912953&MinimumDelay=50&output_format=json&_r=1736538886459 [-]
    [latest-24366]2025-01-10T19:55:09.646Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20050: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20050) [-]
    [latest-24366]2025-01-10T19:55:09.646Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:09.646Z <VeraController:CRIT> *Entity#vera>device_20050
    [latest-24366]2025-01-10T19:55:09.656Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20570: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20570) [-]
    [latest-24366]2025-01-10T19:55:09.656Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:09.656Z <VeraController:CRIT> *Entity#vera>device_20570
    [latest-24366]2025-01-10T19:55:09.678Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20610: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20610) [-]
    [latest-24366]2025-01-10T19:55:09.679Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:09.679Z <VeraController:CRIT> *Entity#vera>device_20610
    [latest-24366]2025-01-10T19:55:09.744Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20631: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20631) [-]
    [latest-24366]2025-01-10T19:55:09.744Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:09.744Z <VeraController:CRIT> *Entity#vera>device_20631
    [latest-24366]2025-01-10T19:55:09.889Z <VeraController:NOTICE> VeraController#vera reload detected!
    [latest-24366]2025-01-10T19:55:09.910Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20050: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20050) [-]
    [latest-24366]2025-01-10T19:55:09.910Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:09.910Z <VeraController:CRIT> *Entity#vera>device_20050
    [latest-24366]2025-01-10T19:55:09.935Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20570: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20570) [-]
    [latest-24366]2025-01-10T19:55:09.936Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:09.936Z <VeraController:CRIT> *Entity#vera>device_20570
    [latest-24366]2025-01-10T19:55:09.937Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20610: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20610) [-]
    [latest-24366]2025-01-10T19:55:09.937Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:09.937Z <VeraController:CRIT> *Entity#vera>device_20610
    [latest-24366]2025-01-10T19:55:09.939Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20631: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20631) [-]
    [latest-24366]2025-01-10T19:55:09.939Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:09.939Z <VeraController:CRIT> *Entity#vera>device_20631
    [latest-24366]2025-01-10T19:55:09.968Z <Controller:INFO> VeraController#vera 0 dead entities older than 86400000s purged
    [latest-24366]2025-01-10T19:55:10.037Z <VeraController:NOTICE> VeraController#vera reload detected!
    
    

    That repeats until something like this:

    [latest-24366]2025-01-10T19:55:10.049Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20050: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20050) [-]
    [latest-24366]2025-01-10T19:55:10.049Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:10.049Z <VeraController:CRIT> *Entity#vera>device_20050
    [latest-24366]2025-01-10T19:55:10.053Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20570: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20570) [-]
    [latest-24366]2025-01-10T19:55:10.053Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:10.053Z <VeraController:CRIT> *Entity#vera>device_20570
    [latest-24366]2025-01-10T19:55:10.062Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20610: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20610) [-]
    [latest-24366]2025-01-10T19:55:10.062Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:10.062Z <VeraController:CRIT> *Entity#vera>device_20610
    [latest-24366]2025-01-10T19:55:10.112Z <VeraController:WARN> VeraController#vera failed to apply attribute scene_activation.scene_id to Entity#vera>device_20631: [TypeError] Can't set NaN on attribute scene_activation.scene_id (vera>device_20631) [-]
    [latest-24366]2025-01-10T19:55:10.112Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:10.113Z <VeraController:CRIT> *Entity#vera>device_20631
    [latest-24366]2025-01-10T20:00:05.003Z <Engine:INFO> [Engine]Engine#1 master timer tick, local time "10/01/2025 20:00:05" (TZ offset 0 mins from UTC)
    [latest-24366]2025-01-10T20:13:51.872Z <Rule:INFO> No motion in Cinema (rule-m4ocglke in Cinema Environment) evaluated; rule state transition from SET to RESET!
    [latest-24366]2025-01-10T20:13:51.882Z <Rule:INFO> Cinema Heater On (rule-m4ocf1di in Cinema Environment) evaluated; rule state transition from RESET to SET!
    [latest-24366]2025-01-10T20:13:51.888Z <Engine:INFO> Enqueueing "Cinema Heater On<SET>" (rule-m4ocf1di:S)
    

    And the errors / reloads just stop.

    From Openluup:

    2025-01-10 19:49:56.379   luup_log:63: BroadLink_Mk2 debug: RM3 Mini - IR 1: urn:schemas-micasaverde-com:device:IrTransmitter:1
    2025-01-10 19:50:00.085   luup_log:0: 14Mb, 1.7%cpu, 36.1days
    2025-01-10 19:50:07.591   luup.variable_set:: 20160.urn:micasaverde-com:serviceId:EnergyMetering1.KWH was: 18.6793008 now: 18.6805008 #hooks:0
    2025-01-10 19:50:07.591   luup.variable_set:: 20160.urn:micasaverde-com:serviceId:EnergyMetering1.KWHReading was: 1736538000 now: 1736538600 #hooks:0
    2025-01-10 19:50:07.591   luup.variable_set:: 20160.urn:micasaverde-com:serviceId:EnergyMetering1.Watts was: 7.4 now: 7.3 #hooks:0
    2025-01-10 19:50:07.591   luup.variable_set:: 20170.urn:micasaverde-com:serviceId:EnergyMetering1.KWH was: 32.2417984 now: 32.2470016 #hooks:0
    2025-01-10 19:50:07.591   luup.variable_set:: 20170.urn:micasaverde-com:serviceId:EnergyMetering1.KWHReading was: 1736538000 now: 1736538600 #hooks:0
    2025-01-10 19:50:07.591   luup.variable_set:: 20330.urn:micasaverde-com:serviceId:EnergyMetering1.KWHReading was: 1736538000 now: 1736538600 #hooks:0
    2025-01-10 19:50:07.592   luup.variable_set:: 20770.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped was: 0 now: 1 #hooks:0
    2025-01-10 19:50:07.592   luup.variable_set:: 20770.urn:micasaverde-com:serviceId:SecuritySensor1.LastTrip was: 1736534850 now: 1736538607 #hooks:0
    2025-01-10 19:50:07.593   openLuup.server:: request completed (3392 bytes, 1 chunks, 12875 ms) tcp{client}: 0x55c3299a9cf8
    2025-01-10 19:50:07.618   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c3299a9cf8
    2025-01-10 19:50:07.624   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c329d0a5b8
    2025-01-10 19:50:07.624   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912906&MinimumDelay=50&output_format=json&_r=1736538607623 HTTP/1.1 tcp{client}: 0x55c329d0a5b8
    2025-01-10 19:50:07.632   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c3292ed678
    2025-01-10 19:50:07.633   openLuup.server:: GET /data_request?newTargetValue=1&DeviceNum=20060&id=action&serviceId=urn%3Aupnp-org%3AserviceId%3ASwitchPower1&action=SetTarget&output_format=json&_r=1736538607631 HTTP/1.1 tcp{client}: 0x55c3
    292ed678
    2025-01-10 19:50:07.633   luup.call_action:: 20060.urn:upnp-org:serviceId:SwitchPower1.SetTarget 
    2025-01-10 19:50:07.633   luup.call_action:: action will be handled by parent: 37
    2025-01-10 19:50:07.633   luup.variable_set:: 20060.urn:upnp-org:serviceId:SwitchPower1.Target was: 0 now: 1 #hooks:0
    2025-01-10 19:50:07.669   openLuup.server:: request completed (35 bytes, 1 chunks, 35 ms) tcp{client}: 0x55c3292ed678
    2025-01-10 19:50:07.673   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c3292ed678
    2025-01-10 19:50:07.776   openLuup.server:: request completed (821 bytes, 1 chunks, 151 ms) tcp{client}: 0x55c329d0a5b8
    2025-01-10 19:50:07.784   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c329d0a5b8
    2025-01-10 19:50:07.795   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c3287bc8f8
    2025-01-10 19:50:07.796   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912907&MinimumDelay=50&output_format=json&_r=1736538607794 HTTP/1.1 tcp{client}: 0x55c3287bc8f8
    2025-01-10 19:50:08.644   luup.variable_set:: 20060.urn:upnp-org:serviceId:SwitchPower1.Status was: 0 now: 1 #hooks:0
    2025-01-10 19:50:08.950   openLuup.server:: request completed (821 bytes, 1 chunks, 1154 ms) tcp{client}: 0x55c3287bc8f8
    2025-01-10 19:50:08.958   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c3287bc8f8
    2025-01-10 19:50:08.969   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c3297e95a8
    2025-01-10 19:50:08.970   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912908&MinimumDelay=50&output_format=json&_r=1736538608969 HTTP/1.1 tcp{client}: 0x55c3297e95a8
    2025-01-10 19:50:19.181   luup.variable_set:: 20770.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped was: 1 now: 0 #hooks:0
    2025-01-10 19:50:19.585   openLuup.server:: request completed (832 bytes, 1 chunks, 10615 ms) tcp{client}: 0x55c3297e95a8
    2025-01-10 19:50:19.602   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c3297e95a8
    2025-01-10 19:50:19.605   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c328d298a8
    2025-01-10 19:50:19.605   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912909&MinimumDelay=50&output_format=json&_r=1736538619604 HTTP/1.1 tcp{client}: 0x55c328d298a8
    2025-01-10 19:50:34.950   openLuup.server:: request completed (593 bytes, 1 chunks, 15344 ms) tcp{client}: 0x55c328d298a8
    2025-01-10 19:50:34.953   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c328d298a8
    2025-01-10 19:50:34.965   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c328c48a58
    2025-01-10 19:50:34.966   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912909&MinimumDelay=50&output_format=json&_r=1736538634964 HTTP/1.1 tcp{client}: 0x55c328c48a58
    2025-01-10 19:50:34.989   luup.variable_set:: 25019.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped was: 0 now: 1 #hooks:0
    2025-01-10 19:50:34.990   luup.variable_set:: 25019.urn:micasaverde-com:serviceId:SecuritySensor1.LastTrip was: 1736534437 now: 1736538634 #hooks:0
    2025-01-10 19:50:35.094   openLuup.server:: request completed (975 bytes, 1 chunks, 127 ms) tcp{client}: 0x55c328c48a58
    2025-01-10 19:50:35.101   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c328c48a58
    2025-01-10 19:50:35.113   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c32985e298
    2025-01-10 19:50:35.113   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912911&MinimumDelay=50&output_format=json&_r=1736538635111 HTTP/1.1 tcp{client}: 0x55c32985e298
    2025-01-10 19:50:40.255   luup.variable_set:: 25021.urn:micasaverde-com:serviceId:LightSensor1.CurrentLevel was: 0 now: 30 #hooks:1
    2025-01-10 19:50:40.256   scheduler.watch_callback:: 25021.urn:micasaverde-com:serviceId:LightSensor1.CurrentLevel called [20]DataWatcherCallback() function: 0x55c3288a8d20
    2025-01-10 19:50:40.460   openLuup.server:: request completed (835 bytes, 1 chunks, 5346 ms) tcp{client}: 0x55c32985e298
    2025-01-10 19:50:40.472   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c32985e298
    2025-01-10 19:50:40.478   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c329b28238
    2025-01-10 19:50:40.479   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912912&MinimumDelay=50&output_format=json&_r=1736538640478 HTTP/1.1 tcp{client}: 0x55c329b28238
    2025-01-10 19:50:44.471   luup.variable_set:: 25007.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped was: 0 now: 1 #hooks:1
    2025-01-10 19:50:44.472   luup.variable_set:: 25007.urn:micasaverde-com:serviceId:SecuritySensor1.LastTrip was: 1736538400 now: 1736538644 #hooks:0
    2025-01-10 19:50:44.472   scheduler.watch_callback:: 25007.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped called [20]DataWatcherCallback() function: 0x55c3288a8d20
    2025-01-10 19:50:44.775   openLuup.server:: request completed (975 bytes, 1 chunks, 4296 ms) tcp{client}: 0x55c329b28238
    2025-01-10 19:50:44.775   openLuup.server:: request completed (975 bytes, 1 chunks, 4296 ms) tcp{client}: 0x55c329b28238
    2025-01-10 19:50:44.782   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c329b28238
    2025-01-10 19:50:44.793   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c328f1e968
    2025-01-10 19:50:44.793   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912914&MinimumDelay=50&output_format=json&_r=1736538644791 HTTP/1.1 tcp{client}: 0x55c328f1e968
    2025-01-10 19:51:00.122   openLuup.server:: request completed (593 bytes, 1 chunks, 15328 ms) tcp{client}: 0x55c328f1e968
    2025-01-10 19:51:00.125   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c328f1e968
    2025-01-10 19:51:00.136   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c32995b318
    2025-01-10 19:51:00.136   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912914&MinimumDelay=50&output_format=json&_r=1736538660134 HTTP/1.1 tcp{client}: 0x55c32995b318
    2025-01-10 19:51:15.481   openLuup.server:: request completed (593 bytes, 1 chunks, 15344 ms) tcp{client}: 0x55c32995b318
    2025-01-10 19:51:15.484   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c32995b318
    2025-01-10 19:51:15.495   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c32998b068
    2025-01-10 19:51:15.497   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912914&MinimumDelay=50&output_format=json&_r=1736538675493 HTTP/1.1 tcp{client}: 0x55c32998b068
    2025-01-10 19:51:30.869   openLuup.server:: request completed (593 bytes, 1 chunks, 15371 ms) tcp{client}: 0x55c32998b068
    2025-01-10 19:51:30.872   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c32998b068
    2025-01-10 19:51:30.884   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c32905bda8
    2025-01-10 19:51:30.885   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912914&MinimumDelay=50&output_format=json&_r=1736538690882 HTTP/1.1 tcp{client}: 0x55c32905bda8
    2025-01-10 19:51:32.886   luup.variable_set:: 20380.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 21 now: 22 #hooks:0
    2025-01-10 19:51:33.090   openLuup.server:: request completed (841 bytes, 1 chunks, 2205 ms) tcp{client}: 0x55c32905bda8
    2025-01-10 19:51:33.100   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c32905bda8
    2025-01-10 19:51:33.112   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c328de0d58
    2025-01-10 19:51:33.112   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912915&MinimumDelay=50&output_format=json&_r=1736538693111 HTTP/1.1 tcp{client}: 0x55c328de0d58
    2025-01-10 19:51:36.064   luup.variable_set:: 25007.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped was: 1 now: 0 #hooks:1
    2025-01-10 19:51:36.065   scheduler.watch_callback:: 25007.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped called [20]DataWatcherCallback() function: 0x55c3288a8d20
    2025-01-10 19:51:36.369   openLuup.server:: request completed (832 bytes, 1 chunks, 3256 ms) tcp{client}: 0x55c328de0d58
    2025-01-10 19:51:36.377   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c328de0d58
    2025-01-10 19:51:36.387   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c329054188
    2025-01-10 19:51:36.388   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912916&MinimumDelay=50&output_format=json&_r=1736538696386 HTTP/1.1 tcp{client}: 0x55c329054188
    2025-01-10 19:51:37.134   luup.variable_set:: 20380.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 22 now: 21 #hooks:0
    2025-01-10 19:51:37.540   openLuup.server:: request completed (841 bytes, 1 chunks, 1152 ms) tcp{client}: 0x55c329054188
    2025-01-10 19:51:37.553   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c329054188
    2025-01-10 19:51:37.566   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c328d97568
    2025-01-10 19:51:37.566   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912917&MinimumDelay=50&output_format=json&_r=1736538697564 HTTP/1.1 tcp{client}: 0x55c328d97568
    2025-01-10 19:51:41.367   luup.variable_set:: 20380.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 21 now: 22 #hooks:0
    2025-01-10 19:51:41.874   openLuup.server:: request completed (841 bytes, 1 chunks, 4307 ms) tcp{client}: 0x55c328d97568
    2025-01-10 19:51:41.884   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c328d97568
    2025-01-10 19:51:41.895   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c329385678
    2025-01-10 19:51:41.896   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912918&MinimumDelay=50&output_format=json&_r=1736538701894 HTTP/1.1 tcp{client}: 0x55c329385678
    2025-01-10 19:51:57.168   openLuup.server:: request completed (593 bytes, 1 chunks, 15272 ms) tcp{client}: 0x55c329385678
    2025-01-10 19:51:57.171   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c329385678
    2025-01-10 19:51:57.183   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c329b092b8
    2025-01-10 19:51:57.184   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912918&MinimumDelay=50&output_format=json&_r=1736538717182 HTTP/1.1 tcp{client}: 0x55c329b092b8
    2025-01-10 19:52:00.124   luup_log:0: 14Mb, 1.6%cpu, 36.1days
    2025-01-10 19:52:00.476   openLuup.server:: request completed (1841 bytes, 1 chunks, 3292 ms) tcp{client}: 0x55c329b092b8
    2025-01-10 19:52:00.483   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c329b092b8
    2025-01-10 19:52:00.495   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c3297be088
    2025-01-10 19:52:00.495   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912929&MinimumDelay=50&output_format=json&_r=1736538720494 HTTP/1.1 tcp{client}: 0x55c3297be088
    2025-01-10 19:52:09.867   luup.variable_set:: 25021.urn:micasaverde-com:serviceId:LightSensor1.CurrentLevel was: 30 now: 0 #hooks:1
    2025-01-10 19:52:09.868   scheduler.watch_callback:: 25021.urn:micasaverde-com:serviceId:LightSensor1.CurrentLevel called [20]DataWatcherCallback() function: 0x55c3288a8d20
    2025-01-10 19:52:10.071   openLuup.server:: request completed (834 bytes, 1 chunks, 9575 ms) tcp{client}: 0x55c3297be088
    2025-01-10 19:52:10.079   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c3297be088
    2025-01-10 19:52:10.088   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c329c16a08
    2025-01-10 19:52:10.089   openLuup.server:: GET /data_request?id=status&Timeout=15&DataVersion=416912930&MinimumDelay=50&output_format=json&_r=1736538730087 HTTP/1.1 tcp{client}: 0x55c329c16a08
    2025-01-10 19:52:16.194   luup.variable_set:: 20770.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped was: 0 now: 1 #hooks:0
    2025-01-10 19:52:16.195   luup.variable_set:: 20770.urn:micasaverde-com:serviceId:SecuritySensor1.LastTrip was: 1736538607 now: 1736538736 #hooks:0
    2025-01-10 19:52:16.498   openLuup.server:: request completed (976 bytes, 1 chunks, 6409 ms) tcp{client}: 0x55c329c16a08
    2025-01-10 19:52:16.515   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55c329c16a08
    2025-01-10 19:52:16.516   openLuup.io.server:: HTTP:3480 connection from 192.168.70.249 tcp{client}: 0x55c328dbad18
    

    Nothing I can see indicating that Openluup is reloading?

    .249 IP address is the internal IP of the NUC that hosts both Openluup and MSR.

    Any thoughts as to how I can troubleshoot this? It's not a big deal, but would like to get to the bottom of it.

    I should add that all the devices listed in entries like this:

    [latest-24366]2025-01-10T19:55:09.744Z <VeraController:INFO> VeraController#vera class scene_controller meta [Object]{ "source": "urn:micasaverde-com:serviceId:SceneController1/sl_SceneActivated", "expr": "int(value)" } orig  final NaN
    [latest-24366]2025-01-10T19:55:09.744Z <VeraController:CRIT> *Entity#vera>device_20631
    

    Are the tamper switches on Fibaro FGMS001 multifunction detectors, of which I have 4, and they correspond exactly to the devices listed.

    TIA

    C

    The Ex-Vera abuser know as CatmanV2.....

    1 Reply Last reply
    0
    • toggledbitsT Offline
      toggledbitsT Offline
      toggledbits
      wrote on last edited by toggledbits
      #2

      OpenLuup is not Vera. There are differences in the way it operates, and I don't make any representation that I will address those differences in Reactor, and in my view it's better that openLuup addresses them if needed.

      The "reload detected" message is emitted when the "loadtime" value in a user_data or status API response is different from the prior value. On Vera, this indicates that Luup has reloaded (the value is the timestamp of the reload); it remains stable otherwise. If you are seeing this message on openLuup when it hasn't reloaded, that is different from Vera Luup's native behavior.

      That said, the message is informational only. The only action taken is it updates a counter that drives the x_vera_sys.reloads attribute on the system entity for the VeraController instance. Unless you are using this attribute for some purpose, it has no effect on anything and can be safely ignored.

      Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

      1 Reply Last reply
      1
      • CatmanV2C Offline
        CatmanV2C Offline
        CatmanV2
        wrote on last edited by
        #3

        That's fabulously clear. Thanks, as ever

        C

        The Ex-Vera abuser know as CatmanV2.....

        1 Reply Last reply
        0
        • toggledbitsT toggledbits unlocked this topic on
        • toggledbitsT toggledbits locked this topic on
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        Recent Topics

        • Copying a global reaction
          toggledbitsT
          toggledbits
          0
          3
          78

        • [HowTo] Using HABridge with Reactor
          CatmanV2C
          CatmanV2
          0
          9
          374

        • [Reactor] Bug when sending MQTT boolean payloads
          toggledbitsT
          toggledbits
          0
          4
          128

        • Genuinely impressed with Zigbee and HA / Reactor
          therealdbT
          therealdb
          1
          8
          292

        • Difficulty defining repeating annual period
          G
          gwp1
          0
          5
          97

        • Need help with sequence
          therealdbT
          therealdb
          0
          3
          60

        • Possible feature request?
          therealdbT
          therealdb
          0
          5
          161

        • Logic Assistance: Exterior Lights on when Illuminance Below Threshold
          CatmanV2C
          CatmanV2
          0
          11
          337

        • Time series documentation
          tunnusT
          tunnus
          0
          11
          387

        • MQTT templates for ZIgbee scene controller, or a better way?
          CatmanV2C
          CatmanV2
          0
          3
          155

        • Reset a delay
          CatmanV2C
          CatmanV2
          0
          8
          215
        Powered by NodeBB | Contributors
        Hosted freely by 10RUPTiV - Solutions Technologiques | Contact us
        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • Unsolved