New openHab2 EnOcean binding

Hi Dominik (@dominikkv),

thanks a lot for your words and analysing the cpu load on your system. However I am not a linux expert so you have to help me to interpret these values. Between August 7th and August 9th the usage was around 0.5. After updating the binding the usage is around 0.75. So my assumption that the cpu usage is somehow higher is correct. However is this more usage really significant? What does 0.75 usage mean? On my Pi 3 I can still use openhab, shell etc without any problems.

So I integrated 4 NodOn STPH-2-1-05 temperature- & humidity sensors. This works. […] The switch in openHAB reflects the state of the β€œreal” switch and changes its state when I press the physical button.

I love good news :grinning:

But the measurements for current power and total usage do not show up

From your images I can see that you use the β€œsimple item linking mode” (configuration => system => Item linking). I currently do not know why but in this case openhab ignores some metainfo I set on the totalusage and instantpower channel. These channels combine a number with a unit which cannot be cannot be interpreted as a simple number. So could you do me favor and deactivate the simple mode and link these channels to new items again. This time you choose β€œNumber” as item type and β€œEnergy” as dimension for totalusage and β€œPower” as dimension for instantpower.

Also, the other way does not work: if I change the state in OpenHAB, the physical switch does not switch.

There seems to be a bigger problem with this EEP. @sepp99 has the same problems with his PCS234 (uses the same EEP). Teach in seems to be ok (green light flashes) but switching from openhab does not work. I currenty do not know why this does not work, I have to analyse it further. However I can tell you that the PCS234 works flawlessly here at my home, I am using it to monitor my washing machine.

I saw from your other posts that you used or tried to use the Homegear/HomeMatic binding solution in the past. Could you switch your PSC132 with this solution? Did you do a factory reset of your PSC132 to reset former teached in devices?

Best regards
Daniel

Hi Daniel (@fruggy83)

Thanks again for your support. You are right, my NodOn thing was not proper calibrated. After recalibration both items get updated. This means also the status item shows now the expected content β€œRssi 55, repeated 0”.

Here are two poll cycles with the calibrated NodOn thing:

2018-08-13 19:26:08.466 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - polling channels
2018-08-13 19:26:08.471 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived
2018-08-13 19:26:08.474 [TRACE] [nal.transceiver.OpenOceanTransceiver] - sending request
2018-08-13 19:26:08.477 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000707017AD203FF97A9810001050EBBE2FF0064
2018-08-13 19:26:08.494 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received Sync Byte
2018-08-13 19:26:08.499 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received header, data length 1 optional length 0 packet type 2
2018-08-13 19:26:08.503 [TRACE] [nal.transceiver.OpenOceanTransceiver] - publish response
2018-08-13 19:26:08.506 [TRACE] [nal.transceiver.OpenOceanTransceiver] - request without listener
2018-08-13 19:26:08.621 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received Sync Byte
2018-08-13 19:26:08.625 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received header, data length 10 optional length 7 packet type 1
2018-08-13 19:26:08.632 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - publish event for: 050EBBE2
2018-08-13 19:26:08.636 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - D203000004050EBBE20001FFFFFFFF4100
2018-08-13 19:26:08.641 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D203000004050EBBE200 for 050EBBE2 received
2018-08-13 19:31:08.507 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - polling channels
2018-08-13 19:31:08.513 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived
2018-08-13 19:31:08.518 [TRACE] [nal.transceiver.OpenOceanTransceiver] - sending request
2018-08-13 19:31:08.523 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000707017AD203FF97A9810001050EBBE2FF0064
2018-08-13 19:31:08.537 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received Sync Byte
2018-08-13 19:31:08.542 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received header, data length 1 optional length 0 packet type 2
2018-08-13 19:31:08.546 [TRACE] [nal.transceiver.OpenOceanTransceiver] - publish response
2018-08-13 19:31:08.550 [TRACE] [nal.transceiver.OpenOceanTransceiver] - request without listener
2018-08-13 19:31:08.665 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received Sync Byte
2018-08-13 19:31:08.668 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received header, data length 10 optional length 7 packet type 1
2018-08-13 19:31:08.673 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - publish event for: 050EBBE2
2018-08-13 19:31:08.676 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - D203000004050EBBE20001FFFFFFFF4400
2018-08-13 19:31:08.679 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D203000004050EBBE200 for 050EBBE2 received

And here are two poll cycles with the uncalibrated NodOn thing:

2018-08-11 09:35:43.536 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - polling channels
2018-08-11 09:35:43.541 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived
2018-08-11 09:35:43.545 [TRACE] [nal.transceiver.OpenOceanTransceiver] - sending request
2018-08-11 09:35:43.550 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000707017AD203FF97A9810001050EBBE2FF0064
2018-08-11 09:35:43.568 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received Sync Byte
2018-08-11 09:35:43.574 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received header, data length 1 optional length 0 packet type 2
2018-08-11 09:35:43.579 [TRACE] [nal.transceiver.OpenOceanTransceiver] - publish response
2018-08-11 09:35:43.583 [TRACE] [nal.transceiver.OpenOceanTransceiver] - request without listener
2018-08-11 09:35:43.696 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received Sync Byte
2018-08-11 09:35:43.701 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received header, data length 10 optional length 7 packet type 1
2018-08-11 09:35:43.708 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - publish event for: 050EBBE2
2018-08-11 09:35:43.712 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - D2FF000004050EBBE20001FFFFFFFF3400
2018-08-11 09:35:43.717 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D2FF000004050EBBE200 for 050EBBE2 received
2018-08-11 09:40:43.576 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - polling channels
2018-08-11 09:40:43.583 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived
2018-08-11 09:40:43.587 [TRACE] [nal.transceiver.OpenOceanTransceiver] - sending request
2018-08-11 09:40:43.592 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000707017AD203FF97A9810001050EBBE2FF0064
2018-08-11 09:40:43.616 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received Sync Byte
2018-08-11 09:40:43.626 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received header, data length 1 optional length 0 packet type 2
2018-08-11 09:40:43.631 [TRACE] [nal.transceiver.OpenOceanTransceiver] - publish response
2018-08-11 09:40:43.634 [TRACE] [nal.transceiver.OpenOceanTransceiver] - request without listener
2018-08-11 09:40:43.728 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received Sync Byte
2018-08-11 09:40:43.732 [TRACE] [nal.transceiver.OpenOceanTransceiver] - Received header, data length 10 optional length 7 packet type 1
2018-08-11 09:40:43.745 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - publish event for: 050EBBE2
2018-08-11 09:40:43.750 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - D2FF000004050EBBE20001FFFFFFFF3400
2018-08-11 09:40:43.754 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D2FF000004050EBBE200 for 050EBBE2 received

Hey Daniel (@fruggy83),

thanks for your quick answer! To be honest, I’m also not a linux crack and just wanted to show you the chart because you mentioned some possible cpu problems with the new version of your library. So my interpretation is that the version change had no (significant) impact on the cpu load on my system.

Regarding the simple linking mode, I just checked the settings, but simple linking mode is disabled. When I add a new thing I also have to create items and link them together. When I first create the item with a dimension, I cannot link it with the thing’s channel… when I delete the dimension linking is possible… but when I link the item through the β€œ+ Create new Item” option in the thing config, I can set a dimension. But it didn’t lead to success :frowning:

I did a factory reset several times, I paired the device within a range of 5 meters, I tried every combination of linking / creation order, but I cannot switch through openhab and get not measurements. If it helps you I can provide logs with every action you request :slight_smile:

I indeed experimented with the combination of Homegear & OpenHAB. There was some struggle pairing Homegear and the Permundo device, but in the end I was able to switch the device with OpenHAB trough Homegear. The measurement had no problems.

Maybe, would it be easier if I define the Permundo PSC132 & items through config files? I prefer it this way, because then you can put your config under version control :wink:. My first try didn’t work:

Bridge openocean:serialbridge:usb300 "EnOcean Bridge" [ port="/dev/ttyUSB0" ] {
    Thing measurementSwitch 019500F6 "Schalter" [ senderIdOffset=1, sendingEEPId="D2_01_09", receivingEEPId="D2_01_09", broadcastMessages=true ]
} 

Switch c_schalter_state "Status [%s]" <switch> (g_enocean) {channel="openocean:measurementSwitch:usb300:019500F6:generalSwitch"}
Number c_schalter_totalusage "Gesamtverbrauch [%f]" (g_enocean) {channel="openocean:measurementSwitch:usb300:019500F6:totalusage"}
Number c_schalter_instantpower "Momentanverbrauch [%f]" (g_enocean) {channel="openocean:measurementSwitch:usb300:019500F6:instantpower"}

Would you mind telling me how to declare them correctly? Thank you again, Daniel!

@raphael you are using the NodOn SIN-2-RS-01? The next thing I’d like to integrate is a rollershutter, and I have bought the NodOn SIN-2-RS-01, but then found no documentation where it is stated that the device can send & receive position data. So it is possible to shut it down for e.g. 80% by OpenHAB? And OpenHAB knows the current position when it changes? Because I didn’t know whether it supports positioning I have also bought the Permundo PSC152 rollershutter actuator, and now I can choose which one I send back :rofl:

Cheers,
Dominik

Hi Dominik (@dominikkv)

Yes, I am using the NodOn SIN-2-RS-01 based on EEP D2-05-00. Daniel was so nice to implement the support for EEP D2-05-00 based rollershutters. Yes, it is possible to shut it down for e.g. 80% by OH. And OH will be informed if the position of the rollershutter changes due to manual positioning.

The documentation from NodOn is quite reduced to the minimal. What I observed meets the description of the EEP D2-05-00 I found on the web.

Best regards
Raphael

Hi Raphael (@raphael),

sounds like I can add another device to the support list :grinning:
Thanks a lot for your help :+1:

Best regards
Daniel

Thanks, @raphael, for the information. I tend to use the Permundo actuator because they have energy measurement built in, but I’m still not sure :yum:

@fruggy83, I have analysed the telegrams the switch is sending while switching on, measurement updates and switching off, and I am a little bit confused…

// Switching on:
55 00 07 07 01 7A F6 10 01 95 00 F6 30 01 FF FF FF FF 4A 00 77 (RPS telegram (0xF6))
55 00 09 07 01 56 D2 04 60 E4 01 95 00 F6 00 01 FF FF FF FF 43 00 CC (Variable length data telegram (0xD2))

// Measurement updates
55 00 0A 07 01 EB A5 00 00 1E 0C 01 95 00 F6 00 01 FF FF FF FF 44 00 7E (4BS telegram (0xA5))
55 00 0A 07 01 EB A5 00 00 1A 09 01 95 00 F6 00 01 FF FF FF FF 43 00 42 (4BS telegram (0xA5))
55 00 0A 07 01 EB A5 00 00 20 0C 01 95 00 F6 00 01 FF FF FF FF 43 00 F6 (4BS telegram (0xA5))

// Switching off
55 00 07 07 01 7A F6 30 01 95 00 F6 30 01 FF FF FF FF 43 00 34 (RPS telegram (0xF6))
55 00 09 07 01 56 D2 04 60 80 01 95 00 F6 00 01 FF FF FF FF 46 00 D6 (Variable length data telegram (0xD2))

So switching uses two EEPs (F6 & D2) and measurement updates use EEP A5 (I guess A5-38-08?). Is that possible? Can your binding handle those two EEPs (D2 & A5)?

// -------------------------

Update: I have started homegear with my old configs and analysed the settings. There are indeed two EEPs registered:

      ID β”‚ Name                      β”‚ Serial Number β”‚  Address β”‚     Type β”‚ Type Description
─ ───────┼───────────────────────────┼───────────────┼──────────┼──────────┼───────────────────────────────────────────────
       1 β”‚ permundo_1_measurement    β”‚   EOD019500F6 β”‚ 019500F6 β”‚   A51201 β”‚ Automated Meter Reading - Electricity         β”‚
       3 β”‚ permundo_1_switch         β”‚   EOD019500F8 β”‚ 019500F6 β”‚   D20109 β”‚ Switch with local control                     β”‚
─ ───────┴───────────────────────────┴───────────────┴──────────┴──────────┴───────────────────────────────────────────────

Here are some log entries from Homegear where we can see which telegrams are sent/received:

// Receiving update for instantpower
homegear_container | 08/14/18 23:52:14.757 EnOcean packet received (mYenocean, RSSI: -74 dBm): 55000A0701EBA50000150C019500F60001FFFFFFFF4A00BD - Sender address (= EnOcean ID): 0x019500F6
homegear_container | 08/14/18 23:52:14.758 Module EnOcean: Info: CURRENT_VALUE on channel 1 of peer 1 with serial number EOD019500F6 was set to 0x000015.
homegear_container | 08/14/18 23:52:14.758 Module EnOcean: Info: DATA_TYPE on channel 1 of peer 1 with serial number EOD019500F6 was set to 0x01.
homegear_container | 08/14/18 23:52:14.758 Module EnOcean: Info: DIVISOR on channel 1 of peer 1 with serial number EOD019500F6 was set to 0x00.
homegear_container | 08/14/18 23:52:14.758 Module EnOcean: Info: TARIFF_INFO on channel 1 of peer 1 with serial number EOD019500F6 was set to 0x00.

// Receive update for totalusage
homegear_container | 08/15/18 00:01:17.642 EnOcean packet received (mYenocean, RSSI: -76 dBm): 55000A0701EBA500001A09019500F60001FFFFFFFF4C0081 - Sender address (= EnOcean ID): 0x019500F6
homegear_container | 08/15/18 00:01:17.643 Module EnOcean: Info: CUMULATIVE_VALUE on channel 1 of peer 1 with serial number EOD019500F6 was set to 0x00001A.
homegear_container | 08/15/18 00:01:17.643 Module EnOcean: Info: DATA_TYPE on channel 1 of peer 1 with serial number EOD019500F6 was set to 0x00.
homegear_container | 08/15/18 00:01:17.643 Module EnOcean: Info: DIVISOR on channel 1 of peer 1 with serial number EOD019500F6 was set to 0x01.
homegear_container | 08/15/18 00:01:17.643 Module EnOcean: Info: TARIFF_INFO on channel 1 of peer 1 with serial number EOD019500F6 was set to 0x00.

// Switching OFF:
homegear_container | 08/15/18 00:30:20.800 Module EnOcean: Info: STATE of peer 3 with serial number EOD019500F8:1 was set to 0x00.
homegear_container | 08/15/18 00:30:20.800 Module EnOcean: Info: Sending packet 550009070156D2014000FF9B08800003019500F6000056

// Switching ON
homegear_container | 08/15/18 00:32:19.443 Module EnOcean: Info: STATE of peer 3 with serial number EOD019500F8:1 was set to 0x64.
homegear_container | 08/15/18 00:32:19.443 Module EnOcean: Info: Sending packet 550009070156D2014064FF9B08800003019500F600000D

The first difference I see in the switching telegrams is that your binding is using the broadcast address as destination, where Homegear uses the device address. Can you help me set up my items with text files? :heart_eyes:

Thanks!
Dominik

Hi Dominik (@dominikkv),

wow thanks a lot for this deep analysis. I guess you have found the solution.

The first difference I see in the switching telegrams is that your binding is using the broadcast address as destination, where Homegear uses the device address.

That is exactly the cause of the problem. I already implemented a config parameter to enable/disable broadcast messages. This parameter should be set to the correct value during teach in. However I found a bug in this source code line (will fix this in the next few days). So you (and @sepp99) have to open your thing in PaperUI and disable broadcast messages for this thing.
broadcast2

As you can see, my PSC234 (uses the same EEP as your PSC132) uses broadcast messages. This should not work but it does. I do not know why :thinking:.

Currently I do not support receiving more than one EEP for a thing. I did not found a case where this is really necessary. The D2-01-09 EEP sends the same measurement data as A5-12-01 EEP. This A5 EEP is used as a fallback mode if you cannot use D2. So let us try to get this thing work with D2. If we do not have success, I will see if I can add another EEP to a thing.

First: As mentioned, disable the broadcast parameter, try to switch your thing.
Second: Use the following config file for your thing and bridge. You have to use a mixed mode. First use PaperUI for teachIn, you get a new thing with a senderIdOffset. Remember the thingID and senderIdOffset and delete the thing. Now you can create your thing config file.

Bridge openocean:serialbridge:usb300 "OpenOcean Gateway" [ port="/dev/ttyUSB0" ] {
   Thing measurementSwitch 019500F6 "PSC132" [senderIdOffset=XYZ, eepId="D2_01_09", broadcastMessages=false, suppressRepeating=false, pollingInterval=300]
}

Replace XYZ with the correct number. This senderIdOffset is stored in your PSC132 during teachIn. It just reacts on this Id, if you use another (not teached in) Id, your switch will not react.

Third: Use the following item file

Switch PSC_Switch "Switch" {channel="openocean:measurementSwitch:usb300:019500F6:generalSwitch"}
Number:Energy PSC_Energy "Gesamtverbrauch" {channel="openocean:measurementSwitch:usb300:019500F6:totalusage"}
Number:Power PSC_Power "Momentanverbrauch" {channel="openocean:measurementSwitch:usb300:019500F6:instantpower"}

Regarding your rollershutter actuators. I do not want to influence your decision, but have in mind that I do not have implemented all of these EEPs used by PSC152 (except D2-01-09). Furthermore this thing sends two different EEPs, A5-11-03 and D2-01-09, which is also not supported by my binding yet.

I hope this helps to get your switch up and running.

Best regards
Daniel

Hi all ( @fruggy83),
I’ve tried your suggestion for the PSC234 and it works like a charm. The only thing I’ve noticed is, that when I switch off a device the values for totalusage and instantpower don’t get update immediately. So I’ve set the pollingInterval to 60. Previously I used the PSCs with FHEM and the behaviour was different. But it isn’t a big deal.

Thank you and regards,
Christoph

Hi Christoph (@sepp99)

I am glad that it works for you now, too. Normally the response to a switch command does not contain any information about the totalusage or instantpower. So I guess fhem just triggers a refresh after switching off or uses the EEP A5-38-08. In this case the EEP A5-12-01 is also actived, which sends directly a message when the current value changes. However this behaviour can also easily be imitated with a rule in openhab. Just create an item state change rule for your switch item and send a refresh command to your totalusage or instantpower items. In this way you can poll these values when it is necessary => less traffic and power consumption.

Best regards
Daniel

Hey Christoph (@fruggy83)

it also works for me, whith the broadcast setting switched to off. I can switch the device with OpenHAB, and the measurement values get updated. Thanks! I am now trying to switch off the A5-12-01 EEP (you can do it with MSC) and configure the D2-01-09 EEP to be sent more often, because the D2 telegram got sent much fewer times than the A5. Can you tell me what the param β€œpollingInterval” does?

I have now chosen the Permundo rollershutter actuator, because it has power measurement build inside. I try to implement the EEP by myself, maybe with your help? In the end your binding does support one more EEP :slight_smile:

One thought for supporting one device with many EEP: Is it possible to declare more than one thing with the same EnoceanID but different EEPs?

Best regards,
Dominik

Hi Dominik (@dominikkv),

I am happy to hear that it works for you now, too :+1:

configure the D2-01-09 EEP to be sent more often, because the D2 telegram got sent much fewer times than the A5. Can you tell me what the param β€œpollingInterval” does?

The pollingInterval defines the time after which the thing requests the device current states. It does a refresh for all its linked channels. So you can configure your device to send D2-01-09 EEP more often or just lower the pollingInterval. It is up to you. However if you want an update after a certain event, it would be better to use a rule or maybe the expire binding with a refresh command.

One thought for supporting one device with many EEP: Is it possible to declare more than one thing with the same EnoceanID but different EEPs?

When I started developing this binding, I thought that it would be very smart to use the EnoceanId as the ThingId (same format, 4 hex bytes). However in the end it was not clever at all, as it prevents defining more than one thing for an enocean device :frowning: . Changing this would have a huge impact on all current installations of this binding.
Let me think about how to handle this problem.

Best regards
Daniel

Hi Dominik (@dominikkv),

I think I found a solution to this multiple EEP one thing problem, which is backward compatible, too.
However as I cannot distinguish two messages of the same profile (like A5-38 from A5-12) from each other, I have to restrict the multiple EEP to different profile types (like D2 and A5). I guess this is also the reason why your PSC152 uses D2-01-09 for energy measurement messages and not A5-12. So this restriction should not be a problem for you as your rollershutter sends D2 for energy measurements and A5 for position.

I hope I find time in the next days to implement this solution.

Best regards
Daniel

Hey Daniel (@fruggy83),

thank you again for your help! In the meantime I got my Permundo PSC234 and it looks like it is a PSC132 in a different housing :slight_smile:. They both send A5 and D2 telegrams in the same way.

So technically you send a D2-01 with CMD 0x6 β€œActuator Measurement Query” and it replies with a D2-01 CMD 0x7 β€œActuator Measurement Response”? I ask because there is a different behaviour between the two profiles D2 and A5 regarding measurement reporting. As far as I can see the D2 profile does only report measurements when you ask it to do so, where the D2 profile sends the telegram everytime the value changes, which leads into a far more β€œrealtime” feeling.

So right now I am trying to turn off A5 profile with an MSC telegram and play around with D2-01 CMD 0x5 β€œActuator Set Measurement”, maybe β€œAuto reporting” sets the behaviour I’d like. By the way, do you know a way to easily send HEX payload to the device without caring about Header, CRC etc.? Right now I am trying to use node-enocean.

Yay, you are the best :heart_eyes:

Cheers,
Dominik

Hi @fruggy83

Do you think it would be possiple to integrate the Soda window sensors without much hassle?

http://www.soda-gmbh.de/en/wireless-handles-with-alarm/

Thank you.

Hi Dominik (@dominikkv),

So technically you send a D2-01 with CMD 0x6 β€œActuator Measurement Query” and it replies with a D2-01 CMD 0x7 β€œActuator Measurement Response”?

That is correct.

So right now I […] play around with D2-01 CMD 0x5 β€œActuator Set Measurement”, maybe β€œAuto reporting” sets the behaviour I’d like.

If it is needed I could add a new channel to these D2-01 devices to set this measurement behaviour directliy in openHAB. I just focused on the more important channels first.

By the way, do you know a way to easily send HEX payload to the device without caring about Header, CRC etc.?

I use my binding for this this, of course :wink: If you want you could use a Generic thing where you just have to define the payload of your messages through a mapping file. Header and CRC is done by the binding. However currently I just support generic things which can send F6, A5 or D2 messages. MSC is not supported yet.

Best regards
Daniel

Hi Christian (@tailor),

I hope everything is fine and the bindig is still running.

Do you think it would be possiple to integrate the Soda window sensors without much hassle?

This is a really really interesting device. It should not be a big problem to support these devices / EEP, too. However as I currently try to implement an official version of this binding, I try to get away of the official EnOcean EEP docs, because it is not fully clear if we can use these information. So I first have to contact Soda if they can provide me the necessary specs.

Best regards
Daniel

Hi Christian (@tailor)

I have just got an answer from Soda. They were really quick and send me detailed information :+1:.
Most of the integrated sensors should work out of the box (temperature, A5-02; humidity, A5-04, handle position, F6-10). Other messages (alarm on/off, window position) can already be handled with a simple Rocker switch (same EEP) and some rules, too. I just have to implement the EEP for the brightness sensor and the messages for controlling the handle (set sensor interval, alarm sound, vacation blink interval etc).

Best regards
Daniel

@fruggy83 This sounds great. How should we proceed? I heard that most of the Soda models are out of stock, so I think the implementation is not not so time-sensitive :wink:

Hi Daniel @fruggy83, (@dominikkv)
how can I get the senderIdOffset which is stored in the PSC234 during techIn? I can add the thing via thing file as mentioned but the switch doesn’t react. I think it’s because of the wrong senderIdOffset.

Thx for your help.

Kind regards.
Christian

Hey guys, (@fruggy83, @dominikkv)

I found it and now my PSC234 is working properly. Thx for that binding.

Looking forward to integrate my other enocean devices.

Kind regards.
Christian