EnOcean ESP3 Gateway plugin

Plugins & Plugin Development General Plugin Discussion
#21

I notice that the plug-in created devices seem to be reporting they are NOT tripped about every thirty seconds?

Is there a reason they need to keep reporting when not changing state? I understand their reporting when their status changes, but the plug-in seems to be checking status too often and taking up a lot of logging space…

Date/Time Class Device No. Device Name Variable Value

20 2014-03-12, 15:17:34.167 S 62 Living Room Occupancy Tripped 0
19 2014-03-12, 15:17:09.178 S 62 Living Room Occupancy Tripped 0
18 2014-03-12, 15:16:44.118 S 62 Living Room Occupancy Tripped 0
17 2014-03-12, 15:16:19.090 S 62 Living Room Occupancy Tripped 0
16 2014-03-12, 15:15:54.161 S 62 Living Room Occupancy Tripped 0
15 2014-03-12, 15:15:29.159 S 62 Living Room Occupancy Tripped 0
14 2014-03-12, 15:15:04.158 S 62 Living Room Occupancy Tripped 0
13 2014-03-12, 15:14:39.158 S 62 Living Room Occupancy Tripped 0
12 2014-03-12, 15:14:14.162 S 62 Living Room Occupancy Tripped 0
11 2014-03-12, 15:13:49.167 S 62 Living Room Occupancy Tripped 0
10 2014-03-12, 15:13:24.170 S 62 Living Room Occupancy Tripped 0
9 2014-03-12, 15:12:59.185 S 62 Living Room Occupancy Tripped 0
8 2014-03-12, 15:12:34.178 S 62 Living Room Occupancy Tripped 0
7 2014-03-12, 15:12:09.159 S 62 Living Room Occupancy Tripped 0
6 2014-03-12, 15:11:44.118 S 62 Living Room Occupancy Tripped 0
5 2014-03-12, 15:11:19.158 S 62 Living Room Occupancy Tripped 0
4 2014-03-12, 15:10:54.097 S 62 Living Room Occupancy Tripped 0
3 2014-03-12, 15:10:29.159 S 62 Living Room Occupancy Tripped 0
2 2014-03-12, 15:10:04.197 S 62 Living Room Occupancy Tripped 0
1 2014-03-12, 15:09:44.521 E 0 Vera RESTART

#22

One entry every 30 seconds, or 2 every minute, means Event Watcher’s 1000 entry buffer is completely filled after 8 hours. So when I want to debug something that happened last night, I am out of luck.

Andrei, can you look at the debugging when you get a chance? I am running the custom version you sent me, so maybe both the occupancy sensor motion trigger functionality and the obsessive logging can be addressed as version 1.3?

#23

Hi all,

Version 1.3 it now available. It includes the occupancy sensor fix and “obsessive logging” issue.

Bests,

  • Andrei -
#24

With 1.3, the Occupancy Sensor is still tripping properly, but never un-tripps. So motion detected once, and motion detector device stays active forever. I will have to bypass my automations until this is resolved. And we are still getting “A valid telegram has been received” messages in the blue notification window…

#25

Hi all,

To help me debugging this kind of bugs, please enable debug mode for the plugin, verbose logging and send me the logs.

Thanks,

  • Andrei -
#26

Looking over the event watcher logs, it looks like the Vera UI device IS un-tripping, but only if no motion is detected for 15 minutes. So unlike normal motion detection, where we expect the device to reset after a few seconds, the plug-in is keeping the device tripped until 15 minutes AFTER no motion has been detected. This is not how the plug-in previously worked, but may be a valid way to do presence detection IF the interval is adjustable. Meaning some situations like a hallway, keeping the lights on 15 minutes after motion stopped would be way too long. Sure, you can check the last tripped timestamp (which keeps getting updated with new motion detection) and calculate the actual time since the last motion, but there are some situations you might want to work with the untripped status, and a hardcoded 15 minutes seems too long to me…

587 2014-03-18, 15:43:58.136 S 62 Living Room Occupancy Tripped 0
586 2014-03-18, 15:28:55.125 S 62 Living Room Occupancy Tripped 1
585 2014-03-18, 15:21:47.092 S 62 Living Room Occupancy Tripped 1
584 2014-03-18, 15:18:42.671 S 62 Living Room Occupancy Tripped 1
583 2014-03-18, 15:16:57.310 S 62 Living Room Occupancy Tripped 1
582 2014-03-18, 15:13:36.284 S 62 Living Room Occupancy Tripped 1
581 2014-03-18, 15:08:13.193 S 62 Living Room Occupancy Tripped 1
580 2014-03-18, 14:57:11.005 S 62 Living Room Occupancy Tripped 1
579 2014-03-18, 14:53:53.145 S 62 Living Room Occupancy Tripped 1

#27

And on the logging, I just didn’t realize the default for advanced setting “DeBug Mode” was 1 - so debug on by default. Maybe if I set this to 0 this messages will stop in the blue VERA notification window?

#28

Hi all,

I uploaded a new version for the plugin. I fixed the issue with DebugMode, but this applies only in the case of a fresh install. For the ones who have the plugin installed and don’t use this feature, please set DebugMode to 0;
I also added “OccupancyReset” variable for setting the period while occupancy sensors remain in tripped state. Default is set to 15 minute based on EnOcean API.

Bests,

  • Andrei -
#29

Is it possible for the plugin to control eltako enocean DIN dimmer modules?

#30

I wanted to thank you for this plugin, it’s really useful.

I did, however, have to make several changes to the code in order to get it to function correctly in my environment. I’m not sure what to do with those changes so I’ll document it here and pass it on if requested.

All of the issues were related to reset processing with respect to Occupancy Sensors. I downloaded the latest 1.5 version from the app store assuming that was the up-to-date one.

First, the reset period was being based on the last tripped value in the gateway. This would be fine with one device, but with several the code runs and simply find the device has “recently” been triggered based on the last tripped time of any device, not the child in question

Next, once in the reset code, the reset loop floods Vera with continuous “untripped” events as the child devices are unconditionally “untripped”, irrespective of actually being tripped or not.

On that subject, the reset loop itself dispatches a timer every 5 seconds, for each and every device. Then in that loop, we’re checking if the time interval (900 seconds by default) has expired. This is the cause of the “untripped” every 5 seconds but it’s also unnecessary as we already know the earliest by which we need to check (last trip + 900, for example) - so that’s 179 superfluous checks every 15 minutes

As it stood - I was either seeing devices as continuously tripped, or seeing never-ending untripped messages.

I didn’t desk check the entire plugin so I can’t comment if I broke anything but in summary. I changed it to:

  • set “tripped” to 0 for the child devices in the startup to remove prior status
  • store the lasttriped (sic) value in the child (not just the gateway)
  • only set “tripped” to 0 in the reset code if the timer has expired and the device actually was tripped
  • schedule the timer to pop after the appropriate reset interval (not every 5 seconds)

I’ve been running with this for some days now, and it seems stable. Even if you did already work on this, it was interesting as I’m trying to understand Vera’s control-flow so as to write some plugins of my own.

#31

[quote=“ToeBroken, post:30, topic:177996”]All of the issues were related to reset processing with respect to Occupancy Sensors. I downloaded the latest 1.5 version from the app store assuming that was the up-to-date one.

First, the reset period was being based on the last tripped value in the gateway. This would be fine with one device, but with several the code runs and simply find the device has “recently” been triggered based on the last tripped time of any device, not the child in question

Next, once in the reset code, the reset loop floods Vera with continuous “untripped” events as the child devices are unconditionally “untripped”, irrespective of actually being tripped or not.

On that subject, the reset loop itself dispatches a timer every 5 seconds, for each and every device. Then in that loop, we’re checking if the time interval (900 seconds by default) has expired. This is the cause of the “untripped” every 5 seconds but it’s also unnecessary as we already know the earliest by which we need to check (last trip + 900, for example) - so that’s 179 superfluous checks every 15 minutes

As it stood - I was either seeing devices as continuously tripped, or seeing never-ending untripped messages.

I didn’t desk check the entire plugin so I can’t comment if I broke anything but in summary. I changed it to:

  • set “tripped” to 0 for the child devices in the startup to remove prior status
  • store the lasttriped (sic) value in the child (not just the gateway)
  • only set “tripped” to 0 in the reset code if the timer has expired and the device actually was tripped
  • schedule the timer to pop after the appropriate reset interval (not every 5 seconds)

I’ve been running with this for some days now, and it seems stable. Even if you did already work on this, it was interesting as I’m trying to understand Vera’s control-flow so as to write some plugins of my own.[/quote]

I don’t know if Andrei responded to you directly, but I had been emailing him these same concerns and he sent me updated code that addressed most of these issues. I don’t think he has released it as 1.6 to the app store yet, but hopefully he will soon…

#32

Hi all,

1.6 version of EnOcean plugin is now available. Fixes for occupancy sensor are included in this version and also I add a “enoceanUIswitch” variable for updating an “EnOcean switch” generated by plugin based on corresponding UI switch generated by “physical EnOcean Gateway” (on every switch generated by plugin you will find this variable. Put here the id of the “physical EnOcean Gateway” and every time it is changing its state, “EnOcean switch” generated by plugin will be updated ).

Bests,

  • Andrei -
#33

I got the 1.6 auto update last night, and so far everything looks great!

#34

I am very happy with 1.6, and plan to add a third occupancy sensor soon.

Are there other users with 3+ occupancy sensors that can share their experience?

#35

Hello i have a rocker switch and a actuator, the rocker switch works vith vera, but i cant control the relay actuator.
and what is the pin code in the enocean app?
thanks

#36

BTW, to make my 4 occupancy sensors more stable, and to get rid of the annoying messages in Vera’s notification window, I commented out the line below in L_EnOceanGateway1.lua

-- ShowSysMessage( "A valid telegram has been received ! Target device : " .. altid .. " Occupancy sensor" )

Honestly, if this plug-in isn’t in debug mode, those messages shouldn’t be generated. Feels a little like a work-in-progress until you comment them out. Afterwards feels like just another sensor in your network, but one you don’t have to ‘heal’…

#37

Hi Will,

Honestly, if this plug-in isn't in debug mode, those messages shouldn't be generated. Feels a little like a work-in-progress until you comment them out.

This was required by EnOcean and this is how it will remain. But for you and other people who find this annoying, there is no problem commenting that line and remove the system message.

Best Regards,

  • Andrei -
#38

May I suggest adding a debug variable and have it set to on by default and let the user turn it off if they choose? It will be easier for the user to turn it on or off. Sounds like a very poor requirement choice on their part.

  • Garrett
#39

@Garrett

DebugMode variable is already implemented. This is about system status message that is displayed. I could do something similar for this too, but I must get a “go for it” first.

  • Andrei -
#40

Has this plug-in been tested with an EnOcean repeater in the network? I have occasional issues with telegrams not being received, and all the documentation indicates a repeater is the way to resolve.

I am about to order a BootUp repeater from Switzerland, as they offer the only stand-alone plug-in (USB power supply) repeater in 315 Mhz. Many room controllers (Leviton) have the repeater function built-in, but I don’t need one of those and I want a repeater I can move around until I get the location right.

I will have about $200 into the repeater when I include the cost to send an international wire. Given that I am already up to 9 occupancy sensors @ $75, plus the working USB adapter and a spare USB adapter at $40 each - I have around $750 into my existing EnOcean network - so another $200 to make that network rock solid (I hope) should be worth it…