This page last changed on Oct 26, 2013 by aktur.

I'm testing few actors with EnOcean. As far as I understand the send interface is implemented only for the F6-02-01 profile (push buttons). However, many actors can work with other sensors too, like D5-00-01 (door contact). Is my understanding correct that right now I cannot send these additional profiles from Openremote, for example from a rule which monitors few temperature sensors and sends TMP command to EnOcean actor?

In this case, are there plans to add the send interface to other profiles beside of F6-02-01?

I know that it's possible to link actors and sensors directly in order to create a decentralized system. In a centralized system with an OpenRemote controller it doesn't make sense to me to send a window/door sensor command from the controller to the actor (except for simulation tasks). It's always possible to create rules and evaluate sensor commands and eventually send a switch command (F6-02-01).

The TELEFUNKEN actors have a very good data sheet (in comparison to devices from other manufacturers) and are in my opinion in conformance to the EnOcean standard requirements. They always list the F6-02-01 profile as a supported EEP (EnOcean Equipment Profile).

Posted by rhitz at Oct 26, 2013 14:41

With ON/OFF actors the F6-02-01 profile is enough, however it would be useful to be able send a set point temperature to central heating installation (I don't know if such EnOcean actuators exists but in the future?). In this situation I would prefer just send the set temperature instead of turning the heating/cooling on/off continuously.

Posted by aktur at Oct 26, 2013 15:00

Heating actuators like the TELEFUNKEN one support the A5-20-01 profile. These actuators are intended for individual room control use cases. This profile contains a field for the temperature set point. OpenRemote doesn't support the profile yet but it's on my todo list.

I think that the new Viessmann Vitocomfort 200 system controls the central heat source via EnOcean. I didn't find any information about the profile they use for controlling the heat source.

Posted by rhitz at Oct 26, 2013 15:36

set point temperature to central heating installation

I know that Eurotronic the makers of my Z-Wave Stella Z radiator thermostatic valve have an Enocean version in their Stella F series. Don't know if it has hit the market already.

A while ago I found the more intriguing iTRV device from Micropelt, which does not use any batteries at all. They informed me this device is under testing this heating season, and it is likely to be released in 2014. For me very tempting to abandon Z-Wave for that more green solution.
edit:fixed the Micropelt link

Posted by pz1 at Oct 26, 2013 15:40

The second device link is the same as the first. However, I've googled it http://www.micropelt.com/applications/smart_valve_itrv.php
and indeed it looks very impressive. I would like to test it too!

Posted by aktur at Oct 27, 2013 16:31

Another good reason to have all profiles with send interface is to use OR as EnOcean development tool (new folks would be interested in OR). Also possibility to test EnOcean actors from within OR would be great, especially when particular sensor with given profile is not available.

Posted by aktur at Oct 29, 2013 12:47

The iTRV seems to have successfully passed field tests last fall See report on their updated page: http://www.micropelt.com/itrv.php.

Posted by pz1 at Mar 25, 2014 12:36

I've just got a sample of the iTRV from Micropelt (beta sample) thanks to Pierre with a request to make a reference implementation. Reiner, how hard is it to add A5-20-01 profile into OR? With the send interface of course? Is there perhaps some similar profile which I can easily tweak into this one?
When I press the learn button I got this in OR log:
DEBUG 2014-04-09 14:27:35,381 (EnOcean): Received radio telegram : [RADIO: RORG=4BS, sender ID=0xFFF79C00, payload=0x80 0x08 0x02 0x80, status=0x00]

Posted by aktur at Apr 09, 2014 13:28

Good news. Seems to be an interesting device. I am curious how well the smartness of that device and that of OpenRemote go together.

Posted by pz1 at Apr 09, 2014 14:32

This is indeed a teach-in telegram that contain the A5-20-01 profile information.

DEBUG 2014-04-09 14:27:35,381 (EnOcean): Received radio telegram : [RADIO: RORG=4BS, sender ID=0xFFF79C00, payload=0x80 0x08 0x02 0x80, status=0x00]

I expect that the integration of this profile is not easy. The device is hard to test (wakes up every 10min or something like that), I have problems to understand the A5-20-01 specification and in addition EnOcean doesn't fit very well to OpenRemote when it comes to sending commands from the controller to the device because a single EnOcean radio telegram may contain several 'channels'. In case of the A5-20-01 profile, the EnOcean radio telegram sent from the controller to the valve, contains the setpoint value or a valve position and the current temperature from a temperature sensor. Maybe this problem can be solved by means of rules (rule provides more than one command parameter). Unfortunately there is not a similar profile available which could be tweaked.

Overall, it will be a challenge - but a rewarding one.

Posted by rhitz at Apr 09, 2014 21:17

Indeed the implementation can be challenging. I think that passing different fields with a single string parameter would be the most flexible. For example we would have:
"direction=1,cv=100,lrn=0" or "direction=2,sp=20.5,sps=1". This of course would be a bit too dense for a typical user.

A different approach can be to aggregate commands with the same enocean device ID. So we would have for each field a separate command defined in the designer. The implementation would join all commands with the same device id to a single enocean telegram.

The ideal would be that we have both methods, the first one for power users which want the maximum flexibility and compact form of passing arguments. The second method could be more useful for regular users.

What do you think?

Posted by aktur at Apr 10, 2014 13:48

I've also thought of the second option, aggregate commands, which would be the logical solution in my opinion. I've also played around with this solution for a different device, the TELEFUNKEN smart plug.

What's currently missing in the object model is the notion of a device. Commands are related to a device object, and the device could have configuration parameters. In addition a lifecycle interface (start/stop) for the device object would be nice. Currently, if a new configuration is deployed, the methods EventListener::stop(Sensor sensor) and EventListener::setSensor(Sensor sensor) are called. The stop command is currently the only way to detect that a new configuration is deployed. In addition, I think that commands for sending something from the controller to the device (ExecutableCommand interface) are only instantiated on demand that means if the command is executed (I have to verify this once again). So aggregating commands if they are not available could be a problem. This in addition with the problem that commands are only added and never removed during deployment time makes the "aggregate" solution a bit hard to implement (currently).

Posted by rhitz at Apr 11, 2014 07:54

This all seems right now very cumbersome and hard to implement.

I think that the 'generic' interface would be helpful. What I mean by this is a generic receiver which would pass all received bytes and generic transmitter which would accept raw bytes string, similarly like TCP/IP protocol can accept raw hex string of arbitrary length. This way, any new EEP could be implemented through rules.

iTRV needs constant bidirectional interaction with the controller. During teach-in controller needs to respond directly after receiving the learning frame. Having the generic interface it would be possible to do this through rules.

Posted by aktur at Apr 14, 2014 20:59

This is indeed a teach-in telegram that contain the A5-20-01 profile information.

How do you decode this from the payload?

Posted by aktur at Apr 15, 2014 13:01

Take a look in 'EnOcean Equipment Specification EEP V2.6' section 3.3 '4BS Teach-in'.

The 6 most significant bits of DB_3 contain the second part of the EEP (xx-20-xx). The following 7 bits contain the third part (xx-xx-01). The first part is derived from the teach-in telegram itself.

Posted by rhitz at Apr 15, 2014 13:36

OK, I've got it. So the first thing I need is to create a teach-in response as iTRV uses variation 3 of the teach-in procedure. Right now it is signalling unsuccessful teach-in and goes to low-power mode, i.e. sending 1 message every hour.
Wouldn't it be useful to generate this teach-in response for each 4BS profile?

Posted by aktur at Apr 15, 2014 14:47

As you've already mentioned, the bidirectional teach-in is only required in case of 'Variation 3' - that means if the teach-in query contains EEP information and the profile requires a bidirectional teach-in procedure. It seems that the teach-in query does not contain the information that a teach-in response is expected. The OpenRemote EnOcean protocol implementation has to know that a device with the profile A5-20-01 expects a two-way teach-in.

I've already started to work on the brand new bidirectional universal teach-in (UTE) procedure ('EnOcean Equipment Specification EEP V2.6' section 3.6 ‚UTE-Universal Uni-and Bidirectional Teach-in') in the branch workspace/rhitz/Controller_2_1_0_ORCJAVA-317. It's not all checked in but maybe this branch is a good starting point. What's currently missing is a central component (e.g. class TeachInManager) for handling all kinds of teach-in procedures. My vision is that in a future OR controller version, learn mode will be activated and after that the central EnOcean teach-in component handles all teach-in procedures and creates or removes respectively devices and commands automatically.

Btw branch workspace/rhitz/Controller_2_1_0_ORCJAVA-427 contains support for dynamic command parameters.

Posted by rhitz at Apr 17, 2014 08:51

@Michal,
Any progress with the iTRV lately?
Pieter

Posted by pz1 at Jun 01, 2014 14:04

Hi Pieter,

it was on hold the last month because of other assignment. However, my plan is to get it up and running before the next heating season, attached to my radiator and controlled by OR to save energy

Posted by aktur at Jun 02, 2014 11:48

Any further news on the iTRV?

My anual natural gas usage has dropped from some 3500 to 2700 m3. Last winter was not cold at all, but I think my "smart" zone control with the StellaZ thermostats has done a bit too. (The utility company used to produce these comparisons with temperature corrections, but not the last two years unfortunately.)

Posted by pz1 at Oct 24, 2014 19:07

Still on my drawing table. Too many distractions, just recently I'm busy with integrating smappee with Openremote. Hopefully I'll be able to add iTRV before the real winter begins.

Posted by aktur at Oct 26, 2014 11:23

Any progress with this?
I did notice that the company has gone trough financial restructuring. Last February they started with serial production of these devices. I am still interested in the results, since ZWave>Me is adding the Enocean protocol to ZWay.

Posted by pz1 at Jul 17, 2015 12:36
Document generated by Confluence on Jun 05, 2016 09:41