Help, keeps triggering

Plugins & Plugin Development Reactor
#1

Hi, I have this reactor, that the last few days, has started to trigger, I have change nothing, in the past few days.

please note that the state “home/night” is false, as I not home, and have not been home the last 48 hrs. (but it still triggers), so “away=true” for 48 hrs. :slight_smile:

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.5 config 20017 cdata 20045 ui 20045 pluginDevice 884 LuaXP 1.0.1
    System: Vera version 1.7.4970 (7.31) on Sercomm G450 ID 36 (Vera Plus); loadtime 1585898984; systemReady 1585899011; ALTUI v2.49; Lua 5.1; JSON dkjson 1.2; UnsafeLua=1
Local time: 2020-04-03T09:37:44+0200; DST=1; Storvorde, North Denmark Denmark; formats %d/%m/%Y %H:%M:%S
House mode: plugin 2; system 2; tracking on
  Sun data: {}
  Geofence: not running
************************************************************************************************************************************
Reactor Auto varme B (#931)
    Version 19082.6 02/29/20 17:34:41
    Message/status: Not tripped
    Condition group "Reactor Sensor 4" (AND)  false as of 09:30:07 <root>
      &-F-housemode in 1,3 [2 at 09:30:07; F/F as of 09:30:07/09:30:07] <condcm0sn42>
      &-T-service Master bedroom - Tem (20044) urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature <= 19.0; output latching [15.8 at 09:30:07; T/T as of 09:30:07/09:30:07] <condcm0son6>
      &-F-service Soveværelset (44) urn:upnp-org:serviceId:TemperatureSetpoint1_Heat/CurrentSetpoint <= 5; output latching [16.00 at 09:30:07; F/F as of 09:30:07/09:30:07] <condcm0zes1>
      &-T-service Window bedroom (720) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 0 [0 at 09:30:07; T/T as of 09:30:07/09:30:07] <condcm0sqfe>
      &-T-service Door Master Bedroom (862) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 0 [0 at 09:30:07; T/T as of 09:30:07/09:30:07] <condfwjhx55>
      &-F-trange bet ,,,21,0,,,,8,0 [1585899007 at 09:30:07; F/F as of 09:30:07/09:30:07] <condcm0xpou>
    Activity root.false
        Device Soveværelset (44) action urn:upnp-org:serviceId:TemperatureSetpoint1/SetCurrentSetpoint( NewCurrentSetpoint="5" )
        Run Lua:
             1: luup.call_action('urn:richardgreen:serviceId:VeraAlert1','DeviceNotification', {Msg='Auto varme sluk', Name='Auto varme sluk', Description='Auto varme sluk', DeviceID=0, HouseModeMask=undefined, Service='', Variables='', Recipients ='cokeman0'}, 443)
             2: return true
    Activity root.true
        Device Soveværelset (44) action urn:upnp-org:serviceId:TemperatureSetpoint1/SetCurrentSetpoint( NewCurrentSetpoint="19.5" )
        Run Lua:
             1: luup.call_action('urn:richardgreen:serviceId:VeraAlert1','DeviceNotification', {Msg='Auto varme tændt', Name='Auto varme tændt', Description='Auto varme tændt', DeviceID=0, HouseModeMask=undefined, Service='', Variables='', Recipients ='cokeman0'}, 443)
             2: return true
    Events
        2020-04-03 09:30:06: Reactor startup (Luup reload)
        2020-04-03 09:30:06: Starting (Luup Startup/Reload)
        2020-04-03 09:30:07: Condition condcm0sn42 test state changed from (nil) to false
        2020-04-03 09:30:07: Condition condcm0sn42 evaluation state changed from (nil) to false
        2020-04-03 09:30:07: Condition condcm0son6 test state changed from (nil) to true
        2020-04-03 09:30:07: Condition condcm0son6 evaluation state changed from (nil) to true
        2020-04-03 09:30:07: Condition condcm0zes1 test state changed from (nil) to false
        2020-04-03 09:30:07: Condition condcm0zes1 evaluation state changed from (nil) to false
        2020-04-03 09:30:07: Condition condcm0sqfe test state changed from (nil) to true
        2020-04-03 09:30:07: Condition condcm0sqfe evaluation state changed from (nil) to true
        2020-04-03 09:30:07: Condition condfwjhx55 test state changed from (nil) to true
        2020-04-03 09:30:07: Condition condfwjhx55 evaluation state changed from (nil) to true
        2020-04-03 09:30:07: Condition condcm0xpou test state changed from (nil) to false
        2020-04-03 09:30:07: Condition condcm0xpou evaluation state changed from (nil) to false
        2020-04-03 09:30:07: Group Reactor Sensor 4 test state changed from (nil) to false
        2020-04-03 09:30:07: Group Reactor Sensor 4 evaluation state changed from (nil) to false
        2020-04-03 09:30:07: Launching Reactor Sensor 4.false activity
        2020-04-03 09:30:07: Launching scene/activity root.false
        2020-04-03 09:30:07: Deferring scene execution, system not ready (root.false:1)
        2020-04-03 09:30:07: Changing RS tripped state to false
        2020-04-03 09:30:12: Starting "root.false" group 1
        2020-04-03 09:30:12: ERROR: Using uninitialized global variable nil
        2020-04-03 09:30:12: Activity "root.false" finished
    Devices
        ZWave (1) urn:schemas-micasaverde-com:device:ZWaveNetwork:1 (19/0); parent 0; plugin -; mfg  model ; dev D_ZWaveNetwork.xml impl 
        Door Master Bedroom (862) urn:schemas-micasaverde-com:device:DoorSensor:1 (4/1); parent 1; plugin -; mfg Aeotec model ZW120; dev D_DoorSensor1.xml impl 
        Master bedroom - Tem (20044) urn:schemas-micasaverde-com:device:TemperatureSensor:1 (17/0); parent 20027; plugin -; mfg  model ; dev D_TemperatureSensor1.xml impl 
        Window bedroom (720) urn:schemas-micasaverde-com:device:DoorSensor:1 (4/1); parent 1; plugin -; mfg Aeotec model ZW120; dev D_DoorSensor1.xml impl 
        Netatmo (20027) urn:akbooer-com:device:NetatmoMetric:1 (12/0); parent 0; plugin 4456; mfg  model ; dev D_NetatmoMetric.xml impl I_Netatmo.xml
        Soveværelset (44) urn:schemas-upnp-org:device:Heater:1 (5/2); parent 1; plugin -; mfg Danfoss model 014G0013; dev D_Heater1.xml impl 
    Watches
        Device #862 Door Master Bedroom service urn:micasaverde-com:serviceId:SecuritySensor1 variable Tripped
        Device #720 Window bedroom service urn:micasaverde-com:serviceId:SecuritySensor1 variable Tripped
        Device #44 Soveværelset service urn:upnp-org:serviceId:TemperatureSetpoint1_Heat variable CurrentSetpoint
        Device #20044 Master bedroom - Tem service urn:upnp-org:serviceId:TemperatureSensor1 variable CurrentTemperature
        Device #884 Reactor service urn:toggledbits-com:serviceId:Reactor variable HouseMode
        Device #931 Reactor Auto varme B service urn:toggledbits-com:serviceId:ReactorSensor variable cdata
        Device #931 Reactor Auto varme B service urn:toggledbits-com:serviceId:ReactorSensor variable TestHouseMode
        Device #931 Reactor Auto varme B service urn:toggledbits-com:serviceId:ReactorSensor variable TestTime
    Special Configuration
        UseReactorScenes = 1
        Retrigger = 0
        FailOnTrouble = 0
        ContinuousTimer = 0
#2

You haven’t told us:

  1. What it’s supposed to do;
  2. How your logic is intended to go about implementing that (translations of non-English names and phrases really helps here, too);
  3. Specifically what it’s doing wrong or not doing and at what times.

I’m particularly suspicious of your use of latching, which I’m afraid most people seem to really misunderstand the operation and use of. You’ve also got some errors in your Lua but I’m pretty sure they are benign and unrelated.

I also note that you restarted Luup about 7 minutes before making this report, so any history that would have been helpful in giving you guidance was erased. I would recommend waiting until the problem surfaces again, and then make a new Logic Summary as soon as possible after (immediately, if you can). Then post that (and please read the posting instructions–I had to fix your post). That will give us enough data about what really happened to see why it’s triggering when you don’t expect it.

Also, these messages:

2020-04-03 09:30:07: Condition condcm0sn42 test state changed from (nil) to false
2020-04-03 09:30:07: Condition condcm0sn42 evaluation state changed from (nil) to false

These are an indication that the ReactorSensor was either disabled and enabled or restarted prior to the Luup reload. If you have actions anywhere else that are doing this, don’t do that. Restarting a ReactorSensor (which includes going from disabled to enable), erases all prior condition state–that’s its job. The way your logic is set up, that will cause the “root.false” activity to run, as it did in this report. If that’s what you mean by “Triggering” that may be your problem. If you are sure your are not doing anything to restart your sensor, or this luup reload is unexpected, I would check free space on your system–you may have too little free space for the system to successfully save user_data, and that’s a BIG problem.

#3

Hi,

Sorry, I’ll see if I can post it the right way next time, but I did not reload anything, i’m not at home, and only have remote access.

The ReactorSensor is standalone, and is designed to be enabled 24/7/365. (and have been running for a very long time, since beginning of last year)

I do not enable/disable it. and the condition “housemode” have been trigger (according to the gui), but as I said i’m not home, and no one else is. that’s the issue.

and I’n not a linux expert, but the output of df -h

df -h
Filesystem Size Used Available Use% Mounted on
rootfs 10.6M 1.4M 9.2M 13% /
/dev/root 8.0M 8.0M 0 100% /rom
tmpfs 124.3M 1.2M 123.1M 1% /tmp
/dev/mtdblock7 10.6M 1.4M 9.2M 13% /overlay
overlayfs:/overlay 10.6M 1.4M 9.2M 13% /
tmpfs 512.0K 0 512.0K 0% /dev
/dev/mtdblock10 50.0M 3.7M 46.3M 7% /storage
/dev/mtdblock10 50.0M 3.7M 46.3M 7% /etc/cmh-firmware
/dev/mtdblock10 50.0M 3.7M 46.3M 7% /etc/cmh-backup
/dev/sda1 3.6G 24.8M 3.4G 1% /tmp/log/cmh
/dev/mtdblock9 9.8M 9.8M 0 100% /mios
/dev/mtdblock10 50.0M 3.7M 46.3M 7% /etc/cmh-ludl
/dev/mtdblock11 19.3M 2.1M 17.1M 11% /ezmi
/dev/mtdblock11 19.3M 2.1M 17.1M 11% /etc/cmh

But as always… Thanks for you fantastic support, and great apps.

#4

There’s nothing that indicates the house mode condition has been met. But then, it’s hard to tell, because the Reactor state was wiped at some point prior to the reload at 9:30:06, so any logging of state transitions or prior state was lost at that moment.

As I said, the state being wiped will make your “is FALSE” activity run when the Reactor evaluates, because it’s going from no state (all the (nil) entries in the Events section of the Logic Summary) to false as if it was running for the first time, so its establishing a new initial state. And that would cause the “Auto varme sluk” message to go out at 09:30:12.

1 Like
#5