Activities dont always run ;-(

Plugins & Plugin Development Reactor
#22

Sure I have several reactor sensors, the two main ones that seem to not work all the time are

  1. HW & CH on and off morning and night
  2. Lights on and off night
    so what happens some of the activities dont always run ie HW CH at 18:00 should set thermostat to 21 HW to on and HW Pump to on, tonight It did not set the thermostat to 21 or turn on the HW pump it just turned on the heat
    but they dont fail consistently its pretty random so I thought I should turn logging on on both the sensors and see which one fails first, then send the log

should I not do that?
Thanks

#23

OK. Go ahead and turn it on for both.

#24

Ok thank you

#25

@rigpapa emailed logs

CH & HW turned on correctly at 18:00 then the heat mode for HW turned off at 19:40 ish but the pump stayed on and thermostat stayed at 21
Thank you
Captured this as well
09/29/20 19:40:01.447 Device_Variable::m_szValue_set device: 14 service: urn:upnp-org:serviceId:HVAC_UserOperatingMode1 variable: ModeTarget was: HeatOn now: Off #hooks: 1 upnp: 0 skip: 0 v:0x137ab88/NONE duplicate:0 <0x766a8520>
06 09/29/20 19:40:01.463 Device_Variable::m_szValue_set device: 44 service: urn:toggledbits-com:serviceId:ReactorSensor variable: cstate was: {“root”:{“statestamp”:1601403302,“stateedge”:{“t”:1601403300,“f”:1601403302},“id”:“root”,“lastvalue”:false,“evalstate”:false,“priorvalue”:true,“valuestamp”:1601403302,“matchcount”:199,“evalstamp”:1601403302,“laststate”:false,“evaledge”:{“t”:1601403300,“f”:1601403302}},“vars”:{“HWRelayMode”:{“lastvalue”:“HeatOn”,“name”:“HWRelayMode”,“valuestamp”:1601398800}},“lastUsed”:1601403692,“cond0”:{“statestamp”:1601403302,“stateedge”:{“t”:1601403300,“f”:1601403302},“id”:“cond0”,“lastvalue”:1601403300,“evalstate”:false,“priorvalue”:1601401200,“valuestamp”:1601403300,“matchcount”:199,“evalstamp”:1601403302,“laststate”:false,“evaledge”:{“t”:1601403300,“f”:1601403302}}} now: {“root”:{“evaledge”:{“f”:1601403302,“t”:1601403300},“stateedge”:{“f”:1601403302,“t”:1601403300},“id”:“root”,“evalstamp”:1601403302,“lastvalue”:false,“evalstate”:false,“priorvalue”:true,“valuestamp”:1601403302,“matchcount”:199,“laststate”:false,“statestamp”:1601403302},“vars”:{“HWRelayMode”:{“name”:“HWRelayMode”,“valuestamp”:1601404801,“changed”:1,“lastvalue”:“Off”}},“lastUsed”:1601404801,“cond0”:{“evaledge”:{“f”:1601403302,“t”:1601403300},“stateedge”:{“f”:1601403302,“t”:1601403300},“id”:“cond0”,“evalstamp”:1601403302,“lastvalue”:1601403300,“evalstate”:false,“priorvalue”:1601401200,“valuestamp”:1601403300,“matchcount”:199,“laststate”:false,“statestamp”:1601403302}} #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x766a8520>
06 09/29/20 19:40:01.484 Device_Variable::m_szValue_set device: 44 service: urn:toggledbits-com:serviceId:ReactorSensor variable: lastacc was: 1601403692 now: 1601404801 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x766a8520>
06 09/29/20 19:40:01.484 Device_Variable::m_szValue_set device: 44 service: urn:toggledbits-com:serviceId:ReactorSensor variable: Message was: Not tripped now: Not tripped #hooks: 0 upnp: 0 skip: 0 v:0x141df58/NONE duplicate:1 <0x766a8520>
06 09/29/20 19:40:01.485 Device_Variable::m_szValue_set device: 14 service: urn:upnp-org:serviceId:HVAC_UserOperatingMode1 variable: ModeStatus was: HeatOn now: Off #hooks: 2 upnp: 0 skip: 0 v:0x137aac0/NONE duplicate:0 <0x766a8520>
07 09/29/20 19:40:01.486 Event::Evaluate 1 hw off scene hw off is true users:1062415 allow:1 <0x766a8520>
08 09/29/20 19:40:01.486 Scene::RunScene running 1 hw off <0x766a8520>
07 09/29/20 19:40:01.487 Event::Evaluate 2 hw on scene hw on is false repeat 0/1 <0x766a8520>
07 09/29/20 19:40:02.620 RAServerSync::SendAlert 0x1810360 PK_Event 32808926482 retries 0 URL https://vera-us-oem-event12.mios.com/event/event/event age: 1 file: err: 0 sess: 0000000E3BCA005F738DCFF7C1E1AE2335386F serv: vera-us-oem-event12.mios.com/vera-us-oem-event12.mios.com <0x768a8520>
04 09/29/20 19:40:06.123

#26

The logs you emailed end before the active time. Can you email them again?

I’m not sure what I’m supposed to be looking at in the posted capture. Did you spot something there you are trying to call my attention to?

#27

This is where it switch off the heat, not sure if it helps

07 09/29/20 19:40:01.486 Event::Evaluate 1 hw off scene hw off is true users:1062415 allow:1 <0x766a8520>
08 09/29/20 19:40:01.486 Scene::RunScene running 1 hw off <0x766a8520>
07 09/29/20 19:40:01.487 Event::Evaluate 2 hw on scene hw on is false repeat 0/1 <0x766a8520>
07 09/29/20 19:40:02.620 RAServerSync::SendAlert 0x1810360 PK_Event 32808926482 retries 0 URL https://vera-us-oem-event12.mios.com/event/event/event age: 1 file: err: 0 sess: 0000000E3BCA005F738DCFF7C1E1AE2335386F serv: vera-us-oem-event12.mios.com/vera-us-oem-event12.mios.com <0x768a8520>

#28

I think there is something wrong with the logging
image

log events to file set to 1 event log max kb left blank

#29

The active messages are there for a different ReactorSensor than the one you’ve been giving me Logic Summaries for. The subject RS of the messages posted is device #44. The log files you attached are for ReactorSensors 40 and 41. I’m not sure where all this is at this point. I feel like I’m trying to hit a moving target. Or maybe you have multiple RS’s trying to control these devices?

Edit: and in this case, by the way, the RS logs for 40 and 41 ending at 19:21 make sense… looking at the logic summary you emailed, #40 thinks HW and pump should be on, and setpoint 21; it has no actions attempted. So something else is almost certainly manipulating the devices in question.

#30

Ok, I do have another reactor sensor which controls just the HW and Pump but it works from a virtual binary switch (Manually turn it on or off if I need more HW at the weekends) and if it was running it should have switched of the pump as well

Ah! also I have another reactor S that gets the state of the HW receiver every 30 minutes to stop it going to sleep…maybe thats causing the problem, I’ll re look at that, thanks

I’m going to delete the HW on the binary and wait again for another failure…dont know why the log file stopped

Thanks again

#31

It didn’t stop. There was nothing for it to log–it wasn’t doing anything, and it wasn’t responsible for turning the device off. It’s idle. That’s why it didn’t have any entries after the Luup reload at 19:21.

1 Like
#32

Ok Thank you for the help

#33

@rigpapa
Sent the logic report and the log for reactor sensor that switches on the lights, it tripped but did not turn them on
Thank you

PS I reset it then tripped it and they still didnt turn on, only when I turned each device on manually did they come on ok

#34

Another Luup reload crash. Your system isn’t stable.

Luup restarts: 19:02:19, 19:02:40, 19:03:17, 19:04:18, 19:04:38, 19:17:41, 19:18:16, 19:18:40, 19:21:56, 19:22:34, 19:22:56

Your system is basically not running at all.

The log shows that the activity ran at 19:02:00 and completed, so it’s likely that Luup is crashing while trying to complete one of the device jobs. I would remove one device at a time and see if you can stabilize the behavior. I’ve emailed you some recommendations on where I think you should start.

#35

Hello Rigpapa

Thank you

#36

For anyone whose interested long version, short version at the end
Firstly 100% this NOT a reactor problem
I split out the activities in some of my reactor sensors so I had
zwave
Hue
RFXtrx Lightwave
All on separate sensors to see if I could see which device was causing reboots etc
Support logged in and said I had two Fibaro 3 in 1 sensors flooding the network - removed them factory reset and added them back - fixed that problem
I set most of the devices to not poll at all and the battery devices to wake after about 65000 secs
Then I removed the RFXtrx433E just to narrow things further
I reinstalled my zwave SRT321 Thermostat and my Secure 302 2 channel receiver - I just felt there might be an issue as they were sometimes unresponsive
I set logging on all my reactor sensors- much easier to understand than the luaupnp.log
System appears to working ok at the moment so I’ll be adding back the RFXtrx soon
Short version
not 100% on exactly what the cause was but thanks to @rigpapa for pointing me in the right direction and for his great Reactor with the logs that are invaluable

1 Like
#37