EnOcean ESP3 Gateway plugin

Hi all,
I tried out a new ESP3 on my VeraLite (latest UI7 release). It took awhile to get it working with help from Vera support (something was wrong with my box causing the plugin to fail). It is now paired with my Leviton WSC04 occupancy sensor. So far it has been working by sending a telegram message indicating that someone is present. This fires and event which triggers one of my scenes.

From this thread I see that the plugin simulates a “no one is present” type of event once a timer expires. When I look at the “tripped” variable I see that it changes from 1 to 0 after the timer expires; cool it seems to be working. However it never fires and event that triggers another one of my scenes.

Is this a know issue with the plugin? Has anyone else seen this? What am I missing?

It sounds like you are saying the tripped event works to run a scene, but the un-tripped event does not?

No, the plug-in should be working fine. I am running UI5 (and will be forever it seems), and it performs as expected - I turn off lights in some scenarios when the timer expires and the state is set to un-tripped. Now, I am using PLEG, not traditional scenes, for all automation related to the occupancy sensors…

Thank you for the reply, Wilme2. Please just ignore my post. It ends up that I was an idiot. The logs show that it was triggering the scene. Because there was no one listed to notify in the scene it never showed up in the device logs.

I apologize for the randomization … I am still coming up to speed with this system.

I have around 10 Leviton WSC04-IRW ceiling mount EnOcean occupancy sensors that work great, but I have an application where wall-mount is required.

I just picked up a Leviton WSWDR-I0W as it is the wall-mount in the same family. Unfortunately it won’t pair with Vera. The product sheet was virtually identical, but I see buried in the install instructions “This product is compatible with LevNet RF Advanced Wireless Wall Switches only. NOTE: This product will not work with LevNet RF
Basic Wireless Wall Switches.” When I look over the product description of the wall switch model numbers listed, I see “Advanced pairing with all transmitters.”

So maybe these do a slightly more complicated pairing process and we could update the plug-in for that process? I assume other EnOcean products might also use this advanced pairing method. Andrei, if I capture the pairing message via DolphinView Advanced would that tell you enough to see if this is feasible?

OK, I when I tried it today, the WSWDR-I0W paired without incident. The sensor isn’t tripping however, even though the logs show the device is recognized and the message is ready to update the device - looks like the message data is just different enough that maybe the plug-in is always interpreting the message as an untripped message, which this class of device apparently sends. See below several working messages and the problematic device 98 AKA 01-00-AA-D7. It is not getting data :FF-FF-FF-FF, but 95-7B-FF-09 instead. Could that be the issue?

50	11/11/14 11:13:38.284	luup_log:58: (EnOceanPlugin::RADIO) Handle radio telegram PROG: A5, senderId: 00-04-3D-7F, status: 00, data: FF-FF-FF-FF <0x2ddf7680>
50	11/11/14 11:13:38.285	luup_log:58: (EnOceanPlugin::4BS)9 Device known: 90 <0x2ddf7680>
06	11/11/14 11:13:38.285	Device_Variable::m_szValue_set device: 90 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 1 #hooks: 2 upnp: 0 v:0xdfb5f8/NONE duplicate:0 <0x2ddf7680>


50	11/11/14 11:15:39.414	luup_log:58: (EnOceanPlugin::RADIO) Handle radio telegram PROG: A5, senderId: 01-00-AA-D7, status: 80, data: 95-7B-FF-09 <0x2ddf7680>
50	11/11/14 11:15:39.415	luup_log:58: (EnOceanPlugin::4BS)9 Device known: 98 <0x2ddf7680>
06	11/11/14 11:15:39.415	Device_Variable::m_szValue_set device: 98 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 0 #hooks: 1 upnp: 0 v:0xdfb5f8/NONE duplicate:0 <0x2ddf7680>
06	11/11/14 11:15:39.418	Device_Variable::m_szValue_set device: 98 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: LastTriped was: 1415725859 now: 1415726139 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2ddf7680>

50	11/11/14 11:16:22.584	luup_log:58: (EnOceanPlugin::RADIO) Handle radio telegram PROG: A5, senderId: 00-04-60-80, status: 01, data: FF-FF-FF-FF <0x2ddf7680>
50	11/11/14 11:16:22.585	luup_log:58: (EnOceanPlugin::4BS)9 Device known: 89 <0x2ddf7680>
06	11/11/14 11:16:22.586	Device_Variable::m_szValue_set device: 89 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 1 now: 1 #hooks: 3 upnp: 0 v:0xdfb5f8/NONE duplicate:0 <0x2ddf7680>


50	11/11/14 11:21:27.624	luup_log:58: (EnOceanPlugin::RADIO) Handle radio telegram PROG: A5, senderId: 00-04-61-F9, status: 00, data: FF-FF-FF-FF <0x2ddf7680>
50	11/11/14 11:21:27.625	luup_log:58: (EnOceanPlugin::4BS)9 Device known: 78 <0x2ddf7680>
06	11/11/14 11:21:27.626	Device_Variable::m_szValue_set device: 78 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 1 now: 1 #hooks: 3 upnp: 0 v:0xdfb5f8/NONE duplicate:0 <0x2ddf7680>

Andrei, it looks to me like the issue is we are looking for data FF-FF-FF-FF, but in the case of this sensor we just need to pay attention to the third hex character FF. For example 95-7B-FF-09. The sensor alternates between FF for tripped and 00 for untripped (which we can continue to ignore). Note the “Status” is also an 80 or 81 instead of 01 or 00.

From DolphinView:

Timestamp	Port	Direction	Type	RORG/Type	Data	ID	Status	OptionalData	SubtelCnt	DestinationID	dBm	SecurityLevel	TickCount	SubtelegramTiming[Tickcount,dBm,Status]
2014-11-11 11:07:44,251	COM3	Incoming	Radio	4BS	95 7B FF 09	100AAD7	80	01 FF FF FF FF 3C 00	1	FFFFFFFF	-60	0	0	
2014-11-11 11:09:45,463	COM3	Incoming	Radio	4BS	95 7B FF 09	100AAD7	80	01 FF FF FF FF 44 00	1	FFFFFFFF	-68	0	0	
2014-11-11 11:14:25,133	COM3	Incoming	Radio	4BS	95 7B FF 09	100AAD7	80	01 FF FF FF FF 3C 00	1	FFFFFFFF	-60	0	0	
2014-11-11 11:20:56,325	COM3	Incoming	Radio	4BS	96 7B FF 09	100AAD7	80	01 FF FF FF FF 44 00	1	FFFFFFFF	-68	0	0	
2014-11-11 11:23:01,025	COM3	Incoming	Radio	4BS	96 7B FF 09	100AAD7	80	01 FF FF FF FF 3F 00	1	FFFFFFFF	-63	0	0	
2014-11-11 11:33:02,580	COM3	Incoming	Radio	4BS	96 7B 00 09	100AAD7	81	01 FF FF FF FF 3B 00	1	FFFFFFFF	-59	0	0	

[quote=“wilme2, post:40, topic:177996”]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…[/quote]

BTW, I wasn’t sure my repeater was really working until I was working with DolphinView yesterday, and I realized all EnOcean nodes were showing full strength (~-60db). I then noted nearly all the messages I was receiving were via the repeater - status showing 1 indicating they had been level 1 repeated… Don’t rush out to follow my lead, but EnOcean repeating is an option, either via room controllers or a dedicated repeater like mine…

I got it working with both the old and new occupancy sensors! As I alluded to above, we just need to switch from the 4th number in the user data, to the 3rd number. So I changed the offset from:

	["4BS_07_PIRS"]      = { 24,  1 },

to:

	["4BS_07_PIRS"]      = { 16,  1 },

and the tripped status is working with the advanced Leviton WSWDR-I0W, as well as the ten WSC04-IRWs…

I have had some deadlock problems with the EnOcean plug-in deadlocking with other processes and causing restarts. Frequently the other process is a PLEG process, but that makes sense as PLEG is doing most of my heavy-lifting in climate, lighting, and security automation. I have spent a lot of time troubleshooting and optimizing my PLEGs, so now I am looking at other processes to see if they can be optimized.

What strikes me immediately when I look at my verbose logging, is that the EnOcean gateway is recursively calling function CheckTime every 5 seconds for every EnOcean device. CheckTime sets occupancy sensors back to untripped if they have not had a telegram within the OccupancyReset number of seconds. But instead of just checking a tripped sensor every OccupancyReset number of seconds, we are checking all sensors 24x7 every 5 seconds. With 11 devices, that is a lot of overhead. In my (slightly) custom version of the plug-in, I commented out the recursive call against all child devices, and replaced it with an explicit call OccupancyReset +1 seconds after a device is tripped. So far seems to work, and this HAS to dramatically reduce the overhead from running the EnOcean plug-in…

Change to CheckTime function, which is just to comment out two lines:

--child = tostring(child) comment out user wilme2 2015-01-05 --luup.call_delay("CheckTime", 5, child) comment out user wilme2 2015-01-05

Change to radio telegram handler 4BS, occupancy sensor section (just the last two lines with my comment at the end, but I wanted you to see where it went…)

[code] – Occupancy sensor

elseif eepFunc == 0x07 then
if not g_childDevices[altid] then
log( “(EnOceanPlugin::4BS)8 Device not known. Return” )
return
end
log( "(EnOceanPlugin::4BS)9 Device known: "… g_childDevices[altid] )
– user wilme2 comment out on 2014-05-02: ShowSysMessage( “A valid telegram has been received ! Target device : " … altid … " Occupancy sensor” )
local tripped = GetValueAtLocation( data, LOCATIONS[“4BS_07_PIRS”] ) – 0…255
–tripped = (tripped > 127) and 0 or 1

			luup.variable_set( SID.SECURITY, "Tripped", tonumber(tripped), g_childDevices[altid] )
			local timeNow = os.time()
			luup.variable_set( SID.SECURITY, "LastTriped", timeNow, g_childDevices[altid] )
			local childforcalldelay = tostring(g_childDevices[altid]) -- user wilme2 added 2015-01-05
			luup.call_delay("CheckTime", (resetTime+1) , childforcalldelay) -- user wilme2 added 2015-01-05
		end

[/code]

Hello,

I plan to test the EnOcean solution with my next VeraEDge in a couple of month and I am wondering that the existing plugin “EnOcean ESP3 Gateway” is oudated in the app Mios server .

Updated:2014-04-16 09:21:27
Current Version:1.6

Note : A dedicated Child Board would be nice in the support forum

Nice work 8)

1.6 is the current version, and for standard occupancy sensors it should work great. (I have approximately 15 Leviton LevNet WSC-04/15). I can’t speak about other devices (light switches, temperature sensors, etc) as I don’t personally have any.

I have been tweaking changes to the version on my system, but unless you have a really busy Vera and you are worried about every CPU cycle, or you have an advanced Occupancy Sensor that sends a more complicated message, then the app store version should work for you. And if you want my current file, PM me and I can send you a copy…

One weird thing about this plug-in is that it has very few users despite the potential of EnOcean. I don’t know of any other active forum members using it. There are a few other users who have posted on this thread, but I don’t think any are still active nor have I seen other users on other threads mention EnOcean.

The other unusual thing is that it is an official Vera plug-in written by Andrei from MiCasaVerde. And as he is fully engaged in other aspects of Vera development, on-going development of a little used plug-in isn’t going to be a priority unless there is a real need.

So if you run into problems, I am following this thread and will try to help out, but I don’t really have a development environment built to test extensive code changes… However, if you capture the EnOcean messaging via DolphinView, or via Vera’s LuaUPnP.log if the device pairs OK but otherwise doesn’t function correctly, then we can probably diagnose the issue…

Count me in as a user of the EnOcean gateway plugin, along with the Leviton WSC04 occupancy sensor. Although the plugin has not been updated in quite some time, it has continued to work perfectly through all the revisions of UI7.

The EnOcean USB300 gateway is available for America countries in the 315 and 902 MHZ frequencies .
But I cannot figure out which frequency is applicable for Central America as there was no certification there ( same for Zwave )

One distributor here is selling some EnOcean devices with 315 Mhz frequency.

As per the EnOcean alliance , the 902 Mhz frequency has better performance than te Mhz frequency … https://www.enocean.com/en/902-mhz-enocean-frequency-for-north-america/

So I will use the 902 Mhz frequency

Definitely go with 902 Mhz - for two reasons not directly related to performance:

[ul][li]Many North American vendors that supported 315 Mhz are phasing it out. Leviton, for example[/li]
[li]The only other DIY HA system I am aware of that supports EnOcean - Zipato Zipabox- only supports 868 and 902 Mhz. I e-mailed them last week to confirm. [/li][/ul]

Thx Wilme2,

I just ordered an Usb Enocean gateway USB300U 902 MHZ on ebay.
Then the USB EnOcean dongle has been installed successfully on my VeraEdge US version at UI7 SW with the 1.6 ESP EnOcean gateway plugin .

Now I need to select a motion sensor 902MHz but looks like that there are not a lot available right now … https://www.enocean-alliance.org/en/products/search/?tx_f03enocean_pi1 … + Filters 902Mhz and Wireless Sensors

EDIT 22/09/2015 : Leviton has a new 902 Mhz motion sensor for ceiling mount (WSC12-M9N) or wall mount ( WSWDR-H9W)
The price is about 130 USD on Amazon … so quite high

Hi guys!

  • Im very new to Vera, I just bought a Vera Edge based on all the good things I read about it on different foras. In particular I read that I could connect EnOcean devices through Vera + suitable plugin for the gateway USB300 868 which one of the most important abilities for me.

I’m currently in the middle of building a house and will install several downlights divided between 9 rooms and 3 floors, I will use ordinary wall pushbuttons for visitors convenience.
But to be able to have more fun (automation/remote) I thought that the following solution would be great:
The ordinary pushbuttons will be wired to a central dimmer that is also wirelessly controlled, one for each group (room/split room) of downlights. I will use eltako’s FUD61NPN actuator (which is EnOceans compatible). This will let me add wireless pushbuttons after the wiring is done as complement to the fixed wall buttons and let me control the lights through Vera+EnOcean gateway.

However I have not succeded in using the gateway/plugin combo. I have installed the EnOcean ESP3 Gateway app (v 1.6) but it does not install correctly i belive, so I wonder if my problem lies in that I have UI7 - in which I cannot see the baud setting for instance (the help says to set baud reate and some other parameters, of which I can see none of)

Is there a requirement to use UI5 in order to make the gateway plugin work perhaps?

VeraEdge = UI7 only

Sorry about that but have you following the installation procedure … EnOcean ESP3 Gateway ?

Others on this thread are using UI7 if you look back a page or two…

The plugin works perfectly with UI7 - up to and including the current version.

You do need to adapt the UI5 installation instructions for UI7. All the required settings are available in UI7 - setting the serial communication parameters is absolutely essential for getting the USB gateway working with Enocean devices.