As you can see, you can now select multiple EEPs for receiving. I even implemented a custom Permundo EEP which provides an Eco Mode channel, through which you can (de)active sending of A5_12_01 or (de)activate the repeater. This solution has currently just one drawback: you can define such a thing only in PaperUI, as it is currently not possible to assigne multiple values to a single config paramter in the thing files (will create an issue for that in ESH).
did you ordered or already own such a Soda handle? I would say that I implement the new EEPs if someone requests it who owns such a device. As I already equiped all my important window and door handles with Hoppe handles I will not order such a handle in the near future.
WOW! That looks very nice! I am currently implementing A5-11-03 and A5-38-08 cmd 7 to handle the rollershutter and right now I get position data from the actuator and I can send position data to it
Later this day Iâll make a push request to your repo and write here in more detail. Until then!
that sounds great, thanks a lot for your work .
As you maybe know I am trying to go official with this binding. I have already done a PR and will update it today or tomorrow. As long as this PR is not accepted yet, we can still work on OpenOcean. However after going official we should discuss how to proceed with the OpenOcean project on the whole and especially with your changes.
so now I have done a pull request on your repo with the following new EEPs:
A5-11-03 for rollershutter position updates from the rollershutter
A5-38-08 cmd 7 to update rollershutter position on the device
A5-12-01 (and others from this family) for electricity measurement readings of the permundo devices
I am not sure whether I have set the EEPTypes etc correctly, so feel free to tell me what to change, or change it yourself I have also done some refactorings regarding logging, if you donât like it revert it.
As I said in my previous posting, I can now controll my rollershutter, and get the current position:
So now for the measurement data, I have tested these and the update interval of the data is much better! I have to combine the EEP A5-12-01 to my existing measurementSwitch with your new feature in development. Iâll do that after you have committed your changes to your repo.
OK, but why is this a problem? Canât I make pull requests to your repo and later on, if there will be a new release of this binding, you push them to the OpenHAB Addons repo? I am also open for other solutions, just tell me how to contribute
Hello,
I installed the latest binding version and saw the bridge option RS485 gateway connection. So I wanted to change my setup but was not able to get it running.
When the USB cable is plugged in to a FAM14, the thing âEnocean USB300 Dongle (A505YP2S)â is found automatically. Here I have switched on the RS485 option and the serial bridge is online.
The bridge ID which I used in PCT14 to teach-in the Eltako actuators is not visible (with USB300 the bridge ID was a HEX which ended on 00 and the things were incremented by 1). I also made another attempt and added a serial bridge manually, so the ID is visible but still the communication openhab - Eltako actuators is not working with the wired setup. Could you please support here?
I want to have the RS485 connection to get the data of the multisensor available in openhab which is connected to a FGW14MS (similar to FWS61). FAM14 is not sending these values in the wireless enocean network (therefore the FTD14 would be needed). FGW14MS is sending two telegrams in EEP A5-13. The plan is to create a generic thing (string) which will be parsed and converted in a rule and updates the values (windspeed, rain, âŠ). Is this a good methode for my purpose?
first thank you for creating this binding. Iâm using Fhem since a long time but nowerdays only for the Enocean part and connecting Fhem and openHAB using http calls. I hope with your binding I can move completely to openHAB now.
I tried to configure the binding to talk to one of my Eltako actuators for switching lights.
The bridge is configured and I managed to create the first actuator thing and a item for it.
If I switch the button in the UI the light goes on! Great! But if I use the real switch there is no status change in openHAB. What to do? Do I need to add all Eltako Acutators to openHAB and create rules?
Regards
Thomas
I am happy to hear that this binding also works for you. Switching your light is more than the half way to a fully working enocean integration. Could you tell me which kind of Eltako actuator you are using? Do you also use the FSR14 or the slightly older 12 series? Which thing type do use to switch your actuator? Do you use the CentralCommand one or VirtualRockerSwitches?
A lot of questions but I am sure that we can solve this last problem, too.
I am sorry to disappoint you, but the RS485 option is not fully implemented and should not even be pushed to github right now. Sorry for this mistake. I have got stuck during the implementation, because of a NRJavaSerial problem on windows systems (a PR of me is still pending ) As I just own a windows mobile dev station I was not able to follow it further and lost sight of it.
However this feature is still on my todo list, I just need some more time. You will be one of the first to know when this feature is implemented.
thanks a lot for your work. This looks really good I have just one or two points which should be changed. I hope to find some time tomorrow for the review.
OK, but why is this a problem?
When this binding gets official I do not know who will be the maintainer of this binding. In any case we have to do an official PR for every change we do to the binding. These PR take some time to be accepted and merged back. Furthermore Kai wanted some renaming (binding [enocean instead of openocean], thing types etc.) and other changes (thingid is no longer the enoceanid instead I should use a separate parameter). These changes make it hard to merge the changes in my openhab repo back to the fork repo. I do not want to maintain two different repos. I will definitely accept your PR and merge it manually to the fork repo (if this is ok for you). But after beeing official I think I will stop working on the OpenOcean repo.
all lights are using FSR14 and all rollershutters (not configured yet) FSB14.
I have configured the things to use the centralCommand not the VirtualRockerSwitches.
all lights are using FSR14 and all rollershutters (not configured yet) FSB14
great! I am using the same hardware setup. Your configuration seems to be ok. Could you do me a favor and look how your FAM14 is setup. In some cases the FAM14 does not send status messages back. Here you find the documentation of your FAM14.
Did your items update with your FHEM combo after pressing your physical switches? How did you setup FHEM to controll your FSR14?
I checked the FAM14 and it is set to position 2.
The status update worked fine with FHEM, there was no change in the Eltako installation.
How does the binding know which actuator belongs to a sender ID of the Enocean Pi?
What I didnât do is unlearn and relearn the combinations again because they are all setup.
Maybe I have to do that again to let the binding know the actuator?
thanks a lot for the trace log. Where did your thingid FFF92220 come from?
You can image your CentralCommand thing as a thing that receives and sends messages. The sender address is build up the base id of your gateway plus the senderIdOffset. In fhem you have to set the subdef parameter to this value.
Your FSR14 sends a response to each message of your thing. To connect this response to your thing you have to set the thingId to your FSR14 id (the id you set in the define part in fhem). I think you just have to change the thingId to FFEAC090 (and change the channel in your item file accordingly)
You do not have the unlearn and relearn everything. Just take your fhem config and do the following conversion:
Id from fhem define => ThingId in openHAB
for the senderIdOffset you have to use a calculator, switch to developer mode, enter the subdef id as a hex number and subtact the base id => Dec (!!!) result is the senderIdOffset in openHAB
Maybe I should implement an automatic conversion tool
Have you selected the Eltako components or was this predefined (by house manufacturer)?
My Eltako components (FAM, FSR, FSB, FUD) were all predefined by our house manufacturer (WeberHaus). I advanced these components just with some NodOn smart plugs, a lot of door/window handles and an outside temperature sensor.
you are right It works, I get status updates for my lights.
Trying the rollershutter now. Can I tell via REST or Node-Red to shutdown to 70% (DOWN 70?) ?
By the way we have the same house manufacturer. I extended my installation - thanks to openHAB - with Z-Wave devices.
Can I tell via REST or Node-Red to shutdown to 70% (DOWN 70?) ?
Yes for sure, you just have to set the shutTime (in seconds) of your rollershutters correctly. For example: Thing rollershutter AABBCC05 "Rollershutter" @ "Kitchen" [ senderIdOffset=3, sendingEEPId="A5_3F_7F_EltakoFSB", receivingEEPId="A5_3F_7F_EltakoFSB", broadcastMessages=true, suppressRepeating=false ] {Channels: Type rollershutter:rollershutter [shutTime=25]}
By the way we have the same house manufacturer.
Hope you had also such a relaxed time during construction as we had. Do you also own a Tecalor heating pump?
thanks to Dominik (@dominikkv), this binding supports now EEP A5-12 (esp. energy measurement), A5-11-03 (rollershutter position) and A5-38-08 (command 7, rollershutter).
.
I have also done some refactorings regarding logging, if you donât like it revert it.
) As I just own a windows mobile dev station I was not able to follow it further and lost sight of it.
I have just one or two points which should be changed. I hope to find some time tomorrow for the review.
because they are all setup.
It works, I get status updates for my lights.