You could try to setup the current 2.5.0.1 version of my binding, you find the current release in my repo. Then define a new EnOcean gateway and ensure that you have set RS485 (you find this option under MORE). Next open the log and switch some of your actuators. I did not saw any log entries with my FAM14, so I did not try further, as the FAM14 is not intended for this use case. I had no time for deeper investigations. You have to set your FGW14 to position 6 => ESP3. position 5 => ESP2 is not supported by my binding and will never be.
If you see log entries coming up, I know that the receiving part is working and just have to optimize the sending part.
I am not a maven expert, so do not take my explanatiosn for granted.
As far as I know, the dependencies (needed features) of any binding are declared directly in openhab in its feature file. So during startup of a binding openhab looks into this file and ensures that all features are loaded before the binding gets activated. The unofficial version of this binding has another maven id to distinguish both versions. Therefore openhab has no information about the needed features of this binding and I do not know how to tell openhab what is needed.
What we could try to do, I could change the maven id to the same id of the official binding and see what wil happen. Maybe I find some time in the next days to test this out. Or does anybody else have another idee?
thanks for this hint. It seems that something during cleanup (dispose) is not working The handler should be disposed but still tries to trigger events. I will investigate this.
Same for me. Great that you are still so active on this topic!
I did not find too much time to work on my personal home automation last year, not to mention helping so many others.
My Setup already looks like this, except that I use âbinding-enocean - 2.5.0.SNAPSHOTâ from the snapshots. I double checked the the settings ârs485â: true and FGW14-USB set to 6.
lsof tells me openhab has opened â/dev/ttyUSB0â.
But even if I set the log level to DEBUG I can not see any messages related to button pushes or any other activity on the RS485 bus.
When I stop openhab2 I can verify with âxxd -p -u /dev/ttyUSB0â that there is activity on the RS485 bus.
Is the needed code only in your repo? Than I will check how to get and deploy it.
Anything else I should try, or may I have missed something?
I did the same test some weeks ago when I asked my question.
Maybe I can tell you why your suggested test will not work:
The protocol in Eltakos RS485 actuator bus is not based on enoceans ESP3 protocol.
They are using the raw enocean radio protocol (ERP) to communicate between FGW14 and the actuators.
This ERP protocol you can see on the FGW14 and also when you connect to FAM14 USB interface.
Using WinEtel (Dolphin Software) will give you a good starting point to see what is going on at this interface.
You can find this software at Eltako download page.
Some additional work on the binding is needed to support these interfaces:
Sending:
The binding has to send the ERP packet before encapsulating it in the ESP3 packet.
Some modifications are required (preamble, checksumâŠ) to fit ERP.
And you will not get an answer as you know it from you ESP3 gateway.
Receiving:
As I described we are a level below ESP3 - so the binding has to listen to ERP directly.
Afterwords the process is the same, because the content is not different from what is encapsulated in the ESP3 telegram you receive from the currently supported gateways.
The documentation for ERP on enoceans web site is not complete. Some additional parts that are visible on the radio is missing. (Sync bytes, lenghth and telegram type)
You can see the content with WinEtel and there are some enocean documents also that are describing this protocol. Let me know if you need more detailsâŠ
With WinEtel it is also possible to send messages (4BS for example) to the eltako actuator bus for testing purposesâŠ
I will also try to support you to make this functionality available.
The protocol in Eltakos RS485 actuator bus is not based on enoceans ESP3 protocol.
This is the needed information. The docs state that just ESP3 supports 57600 baud (Table 1 on page 9). As FAM14 and FGW14 also support this baud I thought that they would also use ESP3. However this is not the case. Both gateways use a TCM120 chip which just supports ESP2. So I guess I also have to implement ESP2 support to support wired connections
Just for clarification:
ERP => EnOcean RADIO Protocol used on the radio channel
ESP => EnOcean SERIAL Protocol used in the wired channel
So an USB300/EnOceanPi gateway and a FAM14/FGW14 gateway use the same protocol ESP in different versions. However the content of an ESP3 and an ESP2 packet is the same, it is just the packaging. I will try to implement a first draft for an ESP2 support this weekend. Thanks a lot Rainer for directing me in the right way.
Iâm happy to provide something helpful, even when some parts of my description are wrong:-)
Yes, this is clear, but my mistake is coming from the other side:
I never thought about, that Elatko is using ESP2 in their own bus because of the wrong baud rate.
Because of this, I never had a detailed look to ESP2 and thought this must be raw radio informationâŠ
But I think you are right.
BTW: The FGW14 is not using any TCMxx chip. There is only a PIC inside to switch the baud rate and do some filtering. It also hides all the remote management stuff between FAM14 and the slaves from the outside.
Iâm looking forward to do the first tests with this implementation.
just finished a first draft for ESP2 support. You can find the current implementation in my repo issue13_ESP2 branch. Receiving ESP2 messages is already working and tested, converting them into ESP3 messages so that they can be used by my EEP classes needs to be tested (@jahnra you have got an email, @xxorde if you want, just send me a pm and I can send you a compiled version too). Maybe I can finish the work next weekend or in two.
unfortunately I did not get the openocean binding on a Windows openHab installation running. I will be happy to test your PushButton fix when it goes into a dev version of the enocean binding. But I hesitate to go back to openocean on my Raspberry because the last time I did not manage to switch to enocean without reinstalling openHab.
I have a question regarding genericThings. I have a window contact from Eltako this one. The EEP is not supported directly by your binding. The EEP is A5-14-0A. So I use this:
The Bridge and the Sensor appears as online in PaperUI and in the debug Log I can see the messages that were received. But unfornatly I can not transform it to an OpenHab Status.
Here is an Log extract:
Received header, data length 10 optional length 7 packet type 1
2019-02-10 12:43:10.615 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for 05114172 payload A593000008051141720000FFFFFFFF4100 received
2019-02-10 12:43:10.619 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A5930000080511417200 for 05114172 received
2019-02-10 12:43:19.520 [WARN ] [rm.AbstractFileTransformationService] - Could not transform â-â with the file âenocean.mapâ : Target value not found in map for â-â
â-â is not the expected value for me. The Status is given with the â08â in the payload above. So how can I access these bytes to do a transformation?
I did some additional testing. I installed the actuall snapshot 2.5.0.2 and declard my thing as an contact with the EEPId=A5_14_01_ELTAKO. I get the Voltage of the Battery and the receiveStatus (RSSI) but not the Status OPEN/CLOSE. Will you add this channel? By the way I think âbatteryStorageâ and âbatteryVoltageâ are reversed.
blame on me. I linked to the post from @shotte and didnât use that EEP. I had a look at github and saw that you already implemented A5_14_09. The Data is the same like A5_14_0A. So I get all my information that I need from my contact.
by the way
is not the right syntax. It have to look like this:
receivingEEPId=âD5_00_01â,âA5_14_01_ELTAKOâ
I have OpenHAB installed via package repository. Tried on raspberry PI3B and linux PC- stable 2.4 and beta version. Using PaperUI to install enocean binding, as it is the openenocean now.
I have two USB300 sticks and none of them are auto discovered.
On manual add I get following errors:
20:05:37.462 [DEBUG] [internal.handler.EnOceanBridgeHandler] - error during bridge init occured
java.io.IOException: Could not find a gateway on given path â/dev/ttyUSB0â, 0 ports available.
at org.openhab.binding.enocean.internal.transceiver.EnOceanSerialTransceiver.Initialize(EnOceanSerialTransceiver.java:54) ~[206:org.openhab.binding.enocean:2.4.0]
TTY info:
[ 865.902036] usb 1-1.1.3: FTDI USB Serial Device converter now attached to ttyUSB0
USB ownership:
root@raspberrypi:/# ls -al /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 veebr 20 19:39 /dev/ttyUSB0
[Edit] It was related to ownership. Adding dialout to openhab user fixed the issue
sudo usermod -a -G dialout openhab
http://x.x.x.x:5000
gives following DEBUG info:
14:42:04.366 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - âenocean:bridge:35572f7câ changed from OFFLINE (CONFIGURATION_PENDING): opening serial port⊠to OFFLINE (CONFIGURATION_ERROR): Port could not be found
14:43:04.350 [INFO ] [.transceiver.EnOceanSerialTransceiver] - Transceiver shutdown
14:43:04.356 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - âenocean:bridge:35572f7câ changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial portâŠ
14:43:04.356 [WARN ] [serial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: http://192.168.1.5:5000
rfc2217://x.x.x.x:5000
gives following DEBUG info:
14:34:23.723 [INFO ] [.transceiver.EnOceanSerialTransceiver] - EnOceanSerialTransceiver initialized
14:34:23.726 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - âenocean:bridge:35572f7câ changed from OFFLINE (CONFIGURATION_PENDING): opening serial port⊠to OFFLINE (CONFIGURATION_PENDING): starting rx threadâŠ
14:34:23.730 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - âenocean:bridge:35572f7câ changed from OFFLINE (CONFIGURATION_PENDING): starting rx thread⊠to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base idâŠ
14:35:23.734 [INFO ] [.transceiver.EnOceanSerialTransceiver] - Transceiver shutdown
the second syntax (path="rfc2217://1.2.3.4:3001") should be the one. Have you tried to wait some more minutes after the failure? I also use the rfc2217 protocol, but it only works the second or third time when initializing.
// Edit: Can you confirm that the ethernet port is working with other software, like socat for example? Did you get any software with your gateway?
And for auto discovery of USB sticks, there was a change where only the original sticks get recognised, because the function did also recognise non-EnOcean sticks. Maybe this is the reason?
Hi,
Thanks for pointing this out. Path is for my case rfc2217://192.168.1.5:5000
I have waited for 10 attempts, all the same.
Socat can open the port and I tested with push button. Could the problem be the format?
With USB 300 COM port I receive in HEX format:
55 00 07 07 01 7A F6 30 FE F5 0A 6E 30 01 FF FF FF FF 46 00 E7
55 00 07 07 01 7A F6 00 FE F5 0A 6E 20 01 FF FF FF FF 44 00 7B
With Thermokon gateway I receive in ASCII format:
A556030530000000FEF50A6E30DB
A558010500000000FEF50A6E209B
The auto discovery of USB sticks works fine after the right permission group was added to openhab. I have one USB300 and one Thermokon USB, both are autodiscovered and work fine.
Hi Daniel, (@fruggy83)
I am interested in using Thermokon SR06 sensor with SmartACK to update the setpoint and heat/cool icons on the thermostats display. A5-10-03 is for one way communication and the D2-11-01 enables updates, mode switchover via Airconfig.
[Edit] The generic thing VLD is supported with D2_FF_FF. The thermostat uses D2-11-01.
I can receive the D2 telegram but I cannot figure out how to map the long raw data to different consequtive variables.Examples are all using bool states. e.g. to receive BYTE 3 as Number setpoint value?
Are you willing to add D2-11-01 EEP to the binding?
I can arrange a compensation for your work effort.
[Edit]: SmartACK info for the D2-11-01
Also my pevious post about the Thermokon STC-Ethernet gateway. Would it be much work to implement this gateway? Basically it is needed to read the data stream in ASCII instead of HEX (compared to USB300)
right now I am working on an implementation for EEP A5-20-04, also for a thermostat, but from Hora. It also uses some kind of âSmartACKâ, so this can be the base for your suggestion.
