@Wuehli This explanation is very helpful, at least for me. Many Thanks!!! I am now using only 1 thing for my physical FT55 and I get the information I want. Thanks for the reply.
1 Like
Hi Daniel @fruggy83,
Thanks for the support and development efforts, unerstandably you have a busy schedule.
I will need to start working on the project using Thermokon SR06 with RH sensor this spring.
Is it feasible for you to implement the D2-11-02 EEP within next month?
I presume you have not had the chance to look into this?
I am willing to support your efforts with 200 € donation.
Best Regards,
Tanel
Hi - I just found this thread. Question:
I am trying out several enocean switches, like the Eltako F6T55B or several Peha switches. Adopting and adding them as things works smoothly, reacting to the trigger events they send does as well. However, I can’t figure out how to identify the button that was pressed.
For example, the F6T55B - see my other thread that I just moved to here - has 6 buttons, where essentially the upper 4 are one device, the lower 2 a second device. Thus, I created two things and some rules, all good. But, the triggers are fired whenever one of the buttons is pressed, and I can, based on the two things, only distinguish between 1-4 and 5-6, but not one specific button.
Same problem I have with the Peha switches.
Thus, I am assuming I am simply missing some information. Looking forward to help!
Thanks!
Hi Tanel @Ratiomatic,
when my current PR gets accepted, I will create a PR for SMACK in the official binding and afterwards another one for the Thermokon devices (EEP D2-11 with all features). However I am not sure about the next release of openhab. If it is too late, we should discuss about merging my changes back to openocean.
I added some new features to the SMACK an D2-11 implementation which are not contained in openocean yet. Automatic teach out upon repeated teach in requests, handle SIG messages to get status about the internal backup battery of the room panel.
Best regards
Daniel
1 Like
Hi Michael @MaMi
could you please show me your rules for handling the buttons? If you simply want to switch something on or off upon a button press you could also just link the channels to an item and use a profile. On/Off and Play/Pause are already implemented. So if you press a button the profile will send an ON/Off or Play/Pause message to the item.
Best regards
Daniel
1 Like
Hi Daniel,
sorry for the delayed reply. Attached some of my rules.
Rules 1&2 react on the trigger sent by an Eltako F6T55B when two of it’s six buttons got pressed. (On that, you can also check my thread https://community.openhab.org/t/eltako-f6t55b-how-to-identify-the-pressed-button on the difficulties I had to get that switch work). Both rules simply turn a light on and off currently.
Rules 3-5 react on the trigger sent by a Peha Enocean switch, and open/close/stop some blinds.
However, what I am trying to do is for example:
if a button is only pressed for a short moment, switch a light on. But when the same button is pressed for a longer time, dimm the light up. I was hoping that this would be somehow supported by the binding, similar to how the Philips Hue binding is supporting the Hue Dimmer Switch (screenshot 6).
other example: when a button is pressed only shortly, start moving blinds up. When same button is pressed longer, start rolling the lamellas only.
I am happy to discuss in more detail, maybe also via confcall, if it helps.
Hi Michael @MaMi,
for the first two rules it should be possible to simply link the channels to your GalerieHelligkeit. However I tried it and since OH3 it is no longer possible to directly link these trigger channels to an item.
BTW @flynux Sorry I missed you post regarding this issue, I will analyse this problem, maybe it is an OH3 issue.
Rules 3-5 cannot be handled by the binding out of the box, as I am not getting these short press/long press messages from eltako rockers. The NodOn soft buttons emit those events short, long and double press.
However it is possible to do it by yourself. You already found a thread about a similar requirement. I already posted some rules there, maybe they give you an idee how to solve your problem. If it is not the case you could pm me and we try to find a solution together.
Best regards
Daniel
Hi @Bize
the PR regarding the EEP D2-50 just got merged today. I would be happy if you could test it.
@Ratiomatic
I will create the PR regarding SMACK in the next days and EEP D2-11 afterwards.
Hello @fruggy83
it would be nice if you could find some time to give me short feedback regarding my posts:
Thank you!
Best regards
Dirk
Hi Daniel (@fruggy83),
i already tried it, but i was not succesfull.
First I updated OH by openhabian-config and then i installed the enocean binding via paper UI (version 2.5.12).
Also i tried to update the enocean bundle in Karaf.
For me it seems like, the binding didn’t change. How can I update it?
Thank you!
Hi @Bize,
you first have to upgrade to OH 3 snapshot. I have not migrated it back to 2.5.
Best regards
Daniel
Hi @fruggy83,
now with OH3, i can find the device (D2-50 ventilation device) only as generic device (same as with OH2). In the Thing settings it is still mentioned: “eep = D2_FF_FF” and Thing type: “Thing whose EEP is unsupported. Use a TRANSFORM to convert things messages.”
When i now link all the available channels, like rollershutter → there is no effect to the device. But: the only thing what it seems to receive is the RSSI signal strength value.
For me it looks like the D2-50 is not available. I also can’t manually add it when I want to add a new Thing.
Any ideas?
BR
Berti
Hi Berti @Bize,
sorry for the misunderstanding. You have to use the OH 3.1 snapshot to be able to use the D2-50 EEP. I just released a new version of the openocean binding right now. So you also could just use this release. Uninstall the official enocean binding and copy the openocean.jar into your addon folder.
Best regards
Daniel
Hi Daniel, (@fruggy83)
ok thank you! I tried now your provided snapshot - thanks a lot for this!
Binding was found from openhab3.
But still not really working:
- It doesn’t find the device when i “SCAN” for it and try to pair. This - by the way - was at least successful under OH2.5
That means in my eyes → from the device side, the pairing should be working. - Then I tried to “Add manually” the device.
First problem was, to get the “EnOceanId”. Furtunately from OH2.5 - as mentioned above - I could get this Id. With this I could pair the device. It seems to be “online”.
Nevertheless so far the device seems not to be paired (displayed at the device). Furthermore via the channelDirect Operation Mode ControlI had no success to change the device’s operation mode. - Also the other channels like
fan speedorair temperaturejust give back NULL.
The Logger shows me the following:
2021-02-25 22:43:47.286 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Received teach in message from 050D3E63
2021-02-25 22:43:47.288 [INFO ] [covery.EnOceanDeviceDiscoveryService] - EnOcean Package discovered, RORG UTE, payload D480FF61000050D2050D3E6300, additional 00FFFFFFFF4100
2021-02-25 22:43:47.289 [ERROR] [ding.enocean.internal.eep.EEPFactory] - Cannot instantiate EEP D2-50-00: null
2021-02-25 22:43:47.291 [ERROR] [ernal.transceiver.EnOceanTransceiver] - Exception in informListeners
(...)
2021-02-25 23:00:52.198 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'LuefterEG_DirectOperationModeControl' received command 1
2021-02-25 23:00:52.212 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 1
2021-02-25 23:00:52.229 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 3 to 1
2021-02-25 23:00:54.691 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'LuefterEG_DirectOperationModeControl' received command 2
2021-02-25 23:00:54.698 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 2
2021-02-25 23:00:54.712 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 1 to 2
2021-02-25 23:00:56.249 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'LuefterEG_DirectOperationModeControl' received command 4
2021-02-25 23:00:56.256 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 4
2021-02-25 23:00:56.267 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 2 to 4
2021-02-25 23:00:57.990 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'LuefterEG_DirectOperationModeControl' received command 11
2021-02-25 23:00:57.995 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 11
2021-02-25 23:00:58.008 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 4 to 11
2021-02-25 23:01:00.866 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'LuefterEG_DirectOperationModeControl' received command 1
2021-02-25 23:01:00.870 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 1
2021-02-25 23:01:00.882 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 11 to 1
2021-02-25 23:01:03.341 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'LuefterEG_DirectOperationModeControl' received command 2
2021-02-25 23:01:03.345 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 2
2021-02-25 23:01:03.355 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 1 to 2
2021-02-25 23:01:05.935 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'LuefterEG_DirectOperationModeControl' received command 4
2021-02-25 23:01:05.941 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 4
2021-02-25 23:01:05.954 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 2 to 4
2021-02-25 23:01:07.765 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'LuefterEG_DirectOperationModeControl' received command 4
2021-02-25 23:01:07.770 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 4
2021-02-25 23:01:10.242 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'LuefterEG_DirectOperationModeControl' received command 13
2021-02-25 23:01:10.246 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 13
2021-02-25 23:01:10.256 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 4 to 13
So far I have no idea how to go on.
I think, the problem is, that the pairing doesn’t run properly. What do you think?
Thanks & Greetings,
Berti
Hi Berti @Bize ,
indeed the pairing does not work. It seems as if the teach in message cannot be handled correctly: Cannot instantiate EEP D2-50-00: null.
As this is an UTE device you have to pair it through the “SCAN” or device discovery. Otherwise it would not react on messages from openHAB.
I will investigate this.
Daniel
HI Berti @Bize ,
I found the bug, message validation does not handle the teach in message correctly. Sorry. I will release a new version tomorrow.
Daniel
Hi Daniel @fruggy83,
ok understood. Sounds good. As soon as you have released the new version, I will test it.
BR
Berti
Hi everyone,
first of all: I’m taking my very first steps with the binding, the whole EnOcean ecosystem in general and the used hardware. I’m struggling to setup an EnOcean gateway with an ESP8266 and the EnOcean Pi module.
I guess this is most likely not an issue with the binding but probably my own inability somewhere along the way… Please let me know if this question is therefore inappropriate in this thread, I will create a new one then.
Since I might be completely on the wrong path so some help would be really appreciated.
This is my current setup:
Board: https://www.az-delivery.de/products/nodemcu with EnOcean Pi from element14
I use the library from: GitHub - Techserv-krY/EnOcean_ESP8266_Gateway: Enocean Gateway 1to1 Telegram to TCP over WiFi, inkl OTA and Wifi Manager / Node-Red
I use the following path: rfc2217://10.9.0.195:9999
The problem:
When I try to connect to the bridge I see that messages to retrieve base id and version are sent out in the TRACE log:
2021-03-09 19:46:02.987 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2021-03-09 19:46:02.989 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request base id
2021-03-09 19:46:02.993 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2021-03-09 19:46:02.995 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 08
2021-03-09 19:46:02.998 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700838
2021-03-09 19:46:02.999 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request version info
2021-03-09 19:46:03.001 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2021-03-09 19:46:03.250 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 03
2021-03-09 19:46:03.252 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700309
2021-03-09 19:47:03.002 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - shutting down transceiver
2021-03-09 19:47:03.004 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2021-03-09 19:47:03.007 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Closing serial output stream
2021-03-09 19:47:03.009 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Closeing serial input stream
2021-03-09 19:47:03.011 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Closing serial port
When connected to the diag port on the esp8266 I see:
Client connected
Net > Ser:: FF FB 00
Net > Ser:: FF FD 00 FF FB 03 FF FD 03 FF FB 2C 55 00 01 00 05 70 08 38
Net > Ser:: 55 00 01 00 05 70 03 09
And then nothing until the binding runs into a timeout apparently.
This is the output of tcpdump -i bond0 -nn -s0 -v host 10.9.0.195 (10.9.0.195 is my gateway and 10.9.0.101 is my openhab instance):
tcpdump: listening on bond0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:24:58.327600 IP (tos 0x0, ttl 64, id 3661, offset 0, flags [DF], proto TCP (6), length 60)
10.9.0.101.39508 > 10.9.0.195.9999: Flags [S], cksum 0x1568 (incorrect -> 0x43e8), seq 2315558440, win 64240, options [mss 1460,sackOK,TS val 3526047793 ecr 0,nop,wscale 7], length 0
22:24:58.434140 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.9.0.101 tell 10.9.0.195, length 46
22:24:58.434192 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.9.0.101 is-at e6:ef:7c:b2:63:9e, length 28
22:24:58.435897 IP (tos 0x0, ttl 255, id 2350, offset 0, flags [none], proto TCP (6), length 48)
10.9.0.195.9999 > 10.9.0.101.39508: Flags [S.], cksum 0x6575 (correct), seq 6667, ack 2315558441, win 2144, options [mss 536,nop,nop,sackOK], length 0
22:24:58.435978 IP (tos 0x0, ttl 64, id 3662, offset 0, flags [DF], proto TCP (6), length 40)
10.9.0.101.39508 > 10.9.0.195.9999: Flags [.], cksum 0x1554 (incorrect -> 0x9c0c), ack 1, win 64240, length 0
22:24:58.436294 IP (tos 0x0, ttl 64, id 3663, offset 0, flags [DF], proto TCP (6), length 43)
10.9.0.101.39508 > 10.9.0.195.9999: Flags [P.], cksum 0x1557 (incorrect -> 0x9c05), seq 1:4, ack 1, win 64240, length 3
22:24:58.688913 IP (tos 0x0, ttl 255, id 2351, offset 0, flags [none], proto TCP (6), length 40)
10.9.0.195.9999 > 10.9.0.101.39508: Flags [.], cksum 0x8e9d (correct), ack 4, win 2141, length 0
22:24:58.689001 IP (tos 0x0, ttl 64, id 3664, offset 0, flags [DF], proto TCP (6), length 60)
10.9.0.101.39508 > 10.9.0.195.9999: Flags [P.], cksum 0x1568 (incorrect -> 0x3d1a), seq 4:24, ack 1, win 64240, length 20
22:24:58.939192 IP (tos 0x0, ttl 255, id 2352, offset 0, flags [none], proto TCP (6), length 40)
10.9.0.195.9999 > 10.9.0.101.39508: Flags [.], cksum 0x8e9d (correct), ack 24, win 2121, length 0
22:24:58.939261 IP (tos 0x0, ttl 64, id 3665, offset 0, flags [DF], proto TCP (6), length 48)
10.9.0.101.39508 > 10.9.0.195.9999: Flags [P.], cksum 0x155c (incorrect -> 0x3d6c), seq 24:32, ack 1, win 64240, length 8
22:24:59.188998 IP (tos 0x0, ttl 255, id 2353, offset 0, flags [none], proto TCP (6), length 40)
10.9.0.195.9999 > 10.9.0.101.39508: Flags [.], cksum 0x8e9d (correct), ack 32, win 2113, length 0
22:25:58.442132 IP (tos 0x0, ttl 64, id 3666, offset 0, flags [DF], proto TCP (6), length 40)
10.9.0.101.39508 > 10.9.0.195.9999: Flags [F.], cksum 0x1554 (incorrect -> 0x9bec), seq 32, ack 1, win 64240, length 0
22:25:58.503090 IP (tos 0x0, ttl 255, id 2354, offset 0, flags [none], proto TCP (6), length 40)
10.9.0.195.9999 > 10.9.0.101.39508: Flags [R.], cksum 0x36d1 (correct), seq 1, ack 33, win 24584, length 0
22:26:03.541689 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.9.0.195 tell 10.9.0.101, length 28
22:26:03.622344 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.9.0.195 is-at 3c:61:05:d4:f6:2c, length 46
My guess is that the code I’m using is just not compatible/broken or whatever. The author advertised his code here a while ago but there was no discussion about it so I’m not sure if anyone ever tried it. Any other suggestions (software or hardware related) are also very welcome!
Ok so the main issue was my incompetence… (as expected)
After wiring the TX - RX correctly I get a response from the gateway (requests and responses get a bit mixed up here):
2021-03-09 23:10:35.836 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2021-03-09 23:10:35.837 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 5 optional length 1 packet type 2
2021-03-09 23:10:36.031 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 03
2021-03-09 23:10:36.032 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700309
2021-03-09 23:10:36.073 [TRACE] [ernal.transceiver.EnOceanTransceiver] - ESP3Packet malformed: 0084800AAA55
I’m not quite sure why the binding thinks that the package is malformed. It thinks that the header is ok:
2021-03-09 23:43:00.616 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 5 optional length 1 packet type 2 but it states that the data is corrupted. However I compared the message to the ESP3 specs and it looks ok to me. I can see the following message being sent from my gateway to OpenHab:
Ser > Net:: 0x55 0x00 0x05 0x01 0x02 0xDB 0x00 0xFF 0xF8 0x84 0x80 0x0A 0xAA
This seems to be a valid response to CO_RD_IDBASE:
0x55 -> Sync Byte
0x00 0x05 -> Data Length
0x01 -> Optional Length
0x02 -> Response OK
0xDB -> CRC8H -> Ok according to Sunshine's Homepage - Online CRC Calculator Javascript
0x00 -> RET OK
0xFF 0xF8 0x84 0x80 -> Base ID within specified range (between 0xFF800000 and 0xFFFFFF80)
0x0A -> Remaining Write Cycles for Base ID -> No idea what that is but there are not restrictions according to the specs
0xAA -> CRC8H -> Ok according to Sunshine's Homepage - Online CRC Calculator Javascript
I have no idea where the leading 00 and the trailing 55 comes from in the log output though:
2021-03-09 23:10:36.073 [TRACE] [ernal.transceiver.EnOceanTransceiver] - ESP3Packet malformed: 0084800AAA55
I don’t believe this (rather unusual) setup will work. In my view the main problem is that the ESP-software “sends Enocean packages 1-1 to tcp/wifi” whereas the biding just expects a serial interface, esp RFC2217 is “Telnet Com Port Control Option”.
So IF the ESP-software IS RFC2217 compliant/compatible it should work, but looking at the github site, the software is intended to be used differently with the associated node-red package.
You could ask the author of the ESP-software about RFC2217 compatibility.