Hi @fruggy83@dominikkv
Please will somebody involved post a short instruction and maybe update the documentation how to utilize the Generic Thing using A5_FF_FF or D2_FF_FF. I have looked trough forums and can’t get an idea how this can be done to receive numeric values, all examples are with MAP transform.
For example if I wanted to read EEP A5-09-04 how to get the raw data and divide it to 3 raw bytes (Temp, Humidity and CO2 value in this case) Should we use this with JS transform?
I think this would solve many seldom used EEPs, that neccessarily do not need full support.
you can enable the debug log with log:set debug org.openhab.binding.enocean
I kept the binding id of the official version, so you do not have to change your config files when you switch between the official version and openocean.
I should be sufficient to just feature:install openhab-transport-serial in the karaf console.
Could you please tell me more about your setup? Is it like RaspPi => FGW14 => BUS => FAM14 => WinEtel? Is WinEtel connected by USB or by radio with FAM14? I just checked again but I cannot image why 256 should be added to the senderId.
for complex and not yet implemented EEP like D2 EEP we must use a Generic Thing in conjunction with a JS transform. A simple MAP transform would be to complicated as you have to list all different combinations in you mapping file. I have not found time yet to document a JS transformation. So if you have time, it would be great if you could create an example.
log:set debug org.openhab.binding.enocean
instead of log:set debug org.openhab.binding.openocean
was successful - thank you!
Yes, it is exactly like this. and FAM14 was connected over USB to WinEtel.
Sending over ttyAMA0 => FGW14 is looking like:
2019-03-26 00:00:49.167 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2019-03-26 00:00:49.171 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F600000000012001FFFFFFFFFF00
But the actuator programmed to address 0x00000101 will respond. With ttyUSB0 over FAM14 this actuator does not respond.
The FGW14 is designed also to connect two series 14 buses. I guess this behaviour is normal to not have a conflict between the actuator status messages of two different buses. I’m sure that FGW14 will modify the sender address when a address between 0 and 255 is received. Because of this, modifying the BaseId in this mode would be great…
With my serial problem I did:
sudo service openhab2 stop sudo openhab-cli clean-cache sudo service openhab2 start feature:install openhab-transport-serial on Karaf
After I was able to receive over ttyAMA0, but after openhab2 restart or reboot the raspi, receiving channel is dead again!
First I need a hint how to access the raw payload, when I just assign a variable to Number there is no update. I also tried the JS transform to just return the value:
(function(inputData) {
return (inputData);
})(input)
Only thing I can get is last update timedate:
11:12:01.985 [TRACE] [ternal.transceiver.EnOceanTransceiver] - Received Sync Byte
11:12:02.002 [TRACE] [ternal.transceiver.EnOceanTransceiver] - >> Received header, data length 12 optional length 7 packet type 1
11:12:02.013 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 050466FE payload D24000E00000B0050466FE0000FFFFFFFF2E00 received
11:12:02.022 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D24000E00000B0050466FE00 for 050466FE received
11:12:02.138 [INFO ] [smarthome.event.ItemStateChangedEvent] - VM_Pressac_VU changed from 2019-03-26T11:11:31.880+0200 to 2019-03-26T11:12:02.118+0200
Hi @Ratiomatic, @JGKK, and all other asking for more info on genericThings
following you find a generic implementation of EEP D2-03-0A. This EEP is used by NodOn SoftButtons. I hope that this example is helpful and can be adopted to any other not yet implemented EEP.
(function(inputData) {
var parts = inputData.split('|'),
hexToBytes = function(hex) {
for (var bytes = [], c = 0; c < hex.length; c += 2)
bytes.push(parseInt(hex.substr(c, 2), 16));
return bytes;
};
if(!parts || parts.length != 2)
return null;
var b = hexToBytes(parts[1]);
switch(parts[0]){
case "genericSwitch":
if(b[1] == 1){
return "OnOffType" + "|" + "ON";
} else if(b[1] == 2){
return "OnOffType" + "|" + "OFF";
}
break;
case "genericRollershutter":
break;
case "genericDimmer":
break;
case "genericNumber":
return "DecimalType" + "|" + b[0];
case "genericColor":
break;
case "genericString":
if(b[1] == 1){
return "StringType" + "|" + "SinglePress";
} else if(b[1] == 2){
return "StringType" + "|" + "DoublePress";
} else if(b[1] == 3){
return "StringType" + "|" + "LongPress";
} else if(b[1] == 4){
return "StringType" + "|" + "LongRelease";
}
break;
case "genericTeachInCMD":
break;
}
return (inputData);
})(input)
The transformation function is provided with a string consisting of “ChannelId” + Pipe + “Payload”. The generic.js file already contains a helper function which converts the payload into a byte array (b). The result of the transformation function has to be “OpenHAB State” + Pipe + “Value”. Just return inputData, if you cannot convert it.
Best regards
Daniel
ps @JGKK I have already implemented the EEP, however as long as it is not published you can use this generic thing approach. The number channel holds the battery status in percent.
Thanks for the clear example. Works fine.
Slight problem is only having one number value as genericNumber
A5-09-04 has 3 Number values, I managed to extract CO2 to genericNumber and humidity + temperature into one genericString.
Is it the best way to solve it right now? Later dividing the string into two numbers using a rule.
does anybody has a NODON temperature & humidity sensor? It is written on the back that it uses EEP A5-04-01. However the teach-in data (received by FHEM) looks like this:
2019.03.09 17:06:02 4 : EnOcean Unknown device with SenderID 051173E2 and STE telegram, activate learning mode.
2019.03.09 17:06:02 5 : EUL dispatch EnOcean:1:31:0324AC221D9CBE457A:051173E2:00:01FFFFFFFF4900
2019.03.09 17:06:02 4 : EnOcean received via EUL: EnOcean:1:31:0324AC221D9CBE457A:051173E2:00:01FFFFFFFF4900
2019.03.09 17:06:02 5 : EnOcean received PacketType: 1 RORG: 31 DATA: 0324AC221D9CBE457A SenderID: 051173E2 STATUS: 00
2019.03.09 17:06:02 4 : EnOcean Unknown device with SenderID 051173E2 and ENC telegram, activate learning mode.
I would not expect RORG 31 here. Does anybody has an idea?
I have one of the Nodon temperature and humidity sensors, don’t know about the teach in message but the teach in and function works without any problems in the openhab enocean binding.
I have found the Eltako document what I was talking about last time:
There you can find on page 3:
“Die ID‘s der FTS12EM-Telegramme werden vom FGW14 vor der Ausgabe auf den BR14-Bus um 255 (0x100) erhöht, da die Antworten der BR14-Aktoren den ID-Bereich von 1-254 belegen.”
So a possibility to be outside of sender ID 0-255 is still very welcome in RS485 mode
But for all of my sensors the binding is working very well!!
thanks a lot for this document. Makes sense to me I will change the binding. In case of a RS485 connection, the SenderId will no longer be checked if it is between 0-255.
So in your case Id range 0-255 => BR14-Aktoren
256-512 => FTS12EM rocker switches
513-xxx => openhab things?
). Here are my DSLs:
I will change the binding. In case of a RS485 connection, the SenderId will no longer be checked if it is between 0-255.