I am slowly running out of ideas. Maybe your actuators do not listen to these rocker switches because of the wrong destination address (the part after xxx30ā¦ this is the thing id). My actuators are ignoring it. When you know the enocean id of your actuators (each channel has a seperate one), you could try to define a new rocker switch and set the thing id to this actuator id. Meanwhile I will update the rocker switch EEP to enfore sending broadcast messages. Give me a second
i have no idea, how to the enocean-id of my actuator. I just tried using the id from my wall-rocker, but it did not work.
Btw. i found my old fhem config. This is how i used to control the light:
#EG Lichtschalter
define EG_Flur1 EnOcean 0022A88E (This is the id from the wall-rocker)
attr EG_Flur1 eventMap B0:on BI:off
attr EG_Flur1 room EnOcean
attr EG_Flur1 subDef XXXXXXXX (This is sender-id, which i still use with openhab)
attr EG_Flur1 subType switch
I updated the binding. Rocker switches send always broadcast messages now. So the message should be identical to your wall rocker switches and fhem messages.
If I remember correcty subType switch means, that you are sending rocker switch messages. If this works in fhem, this must also work with my binding (someday ). This fhem thing is defined as I mentioned too. It listens to your wall rocker to sync the state and sends with another sender id to control your actuator. However step by step, first we have to control your actuator and second keep things in sync.
It works like a charme Funny enough when i switched on Channel B, another light went on (I still have the old fhem-switches programmed in the actuators )
Teach-In also workes perfectly. Tomorrow i will try myself on the dimmers and rolloshutters.
Thank you so much Daniel.
Best regards,
Alex
EDIT 1:
Holy smokes. If i use the discovered wall-rocker as the virtual rocker and link āRockerswitch channel A (Sensor)ā openhab actually syncs the state, meaning if i click on the wall-rocker the light goes on and it showes as is in openhab: https://i.imgur.com/B65Oqsu.png. It looks a bit rubbish, of course, but i think it is a huge win
EDIT 2:
When i configure the switch in HABPanel it works perfectly - syncing the state and everything
glad to hear, that it works now. Thank you for your patience and helping me to improve this binding.
@Syncing
I could not image that it is so easy. However thats the reason why I love openhab.
@Rollershutter
Should be no problem at all. You could use a GenericThing sending RPS messages and link to the rollershutter channel. I just have to enforce the broadcast sending for this thing, too.
@Dimmer
You should already be able to switch you dimmer on and off with the rocker switches. However I do not think it is possible to dimm to a certain value. Dimming with rocker switches is done by pressing and holding the wall rocker switch (at least with my FUD14), but I do not know, if holding a button can be simulated with the openhab gui. Which dimmer do you use, maybe it is possible to directly send a dimm value to this actuator (as I am doing it with my FUD14 => A5-38 central command).
no need to thank me! I am very thankfull for your efforts. And if it is ok for you, i will help you as much as i can, to bring this awesome enocean binding to its max. So if you need me to test something etc. just tell me .
These are all of my actuators i use in my house:
Shutters: Opus GN-A-R12V-JRG-2 // Opus GN-A-U230V-JRG
Dimmer: Opus GN-A-R12V-LZ/UD
If i remember correctly the dimmers in fhem were controlled via a virtual āholding a buttonā-function. But i am not 100% sure. This was my old config:
For sure, testers are always needed and welcome. I just own a couple of Eltako actuators (dimmer, shutter, relay, some sensors) and as we know now they react somehow different to your Opus devices
If I read it correctly, your dimmers also use the same EEP (gateway) as my FUD14. So there is a good chance, that you can control them directly (set on/off/dim value) with the A5-38 device. I just have to enforce the broadcast message.
Do you also still have the config of your shutters? Maybe they can be directly controlled, too.
Sadly no. I had fhem running on a fritzbox 7390 a couple years ago. But this fritzbox broke and i lost my fhem-config. I also forgot to make a more recent backup of the file . But i learned my lesson.
If i remember correctly, the shutter-control wasnĀ“t that much diifferent to the dimmers.
The binding with the device ttyUSB0 is working, the other not. As soon as I unplug the sticks and reverse the order of the ports ttyUSB0 <ā> ttyUSB1 the other binding is working and vice versa
Iām also unable to select ttyUSB1 directly in any of the two bindings. Only ttyACM0 (Zwave dongle) and ttyUSB0 is available as an option.
Output lsusb:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 8087:0aa7 Intel Corp.
Bus 001 Device 005: ID 0658:0200 Sigma Designs, Inc.
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 002: ID 0eef:c000 D-WAV Scientific Co., Ltd
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
The two devices show the same name based on lsusb command (Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC). Could this be the reason?
per default openhab (or better the JAVA VM) can just access ttyUSB0, ttyACM0 and ttyAMA0. To be able to access ttyUSB1 you have to edit /etc/default/openhab2 => line EXTRA_JAVA_OPTS and add your ttyUSB1.
I am sorry that I cannot confirm this solution as I destroyed my openhab installation with the last upgrade 10 minutes ago
I tested the bundle today.
It works quite well, very nicely done!
I am not quite sure about the generic switch ability of the rocker switches though.
It seems like there should perhaps be a different thing type to do this.
Also I donāt understand the Sender ID? Am I supposed to input an EnOcean ID? It will only let me input integers.
Using the automatically discovered rocker switch that switches my standing lamp dimmer as an actuator to do the same from the PC does not work at all. Instead it seems to switch other Rocker Switches. But perhaps I have not quality tested my setup enough yet.
The one thing that is absolutely critical right now is that I have 100% CPU load when using your binding.
As soon as I deactivate the binding with bundle:stop the load goes back down to normal levels.
Any idea why it does this?
thanks a lot for your hint regarding the cpu load. I just changed the way listening for enocean messages. Instead of polling I am using now an event based approach. It would be nice if you could test it again.
I am not quite sure about the generic switch ability of the rocker switches though.
It seems like there should perhaps be a different thing type to do this.
I was also thinking about to seperate the sensor (receiving) and actuator (sending) functionality of rocker switches. However to reduce the number of things and make it easier for the user, I decided to keep both functions in one thing. If you own just unidirectional things and want to sync the state of your physical thing with your openhab items when you press a physical rocker switch, you can even use just a single rocker thing and link the sensor channels to the corresponding actuator channels, as @Casshern did it here.
Also I donāt understand the Sender ID? Am I supposed to input an EnOcean ID? It will only let me input integers.
As most enocean messages are broadcast messages, an enocean device must own an unique id, to clearly assign a message to a device. An enocean gateway (USB300 or enocean pi) can simulate up to 127 different rocker switches or other devices. These simulated rocker switches must own an unique id, too. These ids are created by adding the sender id to the base id. You can see the resulting enocean id in the properties of a thing. This sender id is normally determined automatically. If you create a new (sending) thing (manually or by discovery), the next free sender id will be taken (if you leave this field empty). However rocker switches are special as the sending part is optional. So I cannot assign a sender id to rocker switches automatically (another good reason to seperate the sending and receiving part ).
We can discuss the other things in skype or other IM. I will answer your pm tomorrow.
as you can read in my last post, I changed the way of listening to enocean messages to reduce the cpu load.
So I would recommend you to use the latest version of this binding.
@Casshern
I also added a config parameter to things to enforce sending broadcast messages. I would be glad if you could test the generic thing approach with a mapping file for your lights again. You should be able to use an A5-38 thing for your dimmers now (set broadcast message!). Teach in and control should be possible now.
Thank you very much for your inputs. I added ttyUSB1 to EXTRA_JAVA_OPTS and now it shows up.
Unfortunatelly it still does not work properlyā¦ Iāll try to create an udev rule for a symlink, so that the stick can be addressed via e.g. ā/dev/enocean300ā.
The STPH-2-1-05 uses the EEP A5-04-1. This EEP is not implemented yet, as I do not own a device which uses such a EEP. Whenever the binding recognises a device with an unknow EEP, it creates a generic thing.
So you have two options now:
Implement a javascript mapping function which converts the enocean message into an openhab state. However you can only interpret the temperature value or the humidity value as a generic thing provides just one number channel (for the other value you could use the string channel?).
Wait a few hours until I implemented the EEP
If you cannot wait and choose option 1, it would be great if you post a short how to guide, so that others can go this way in a similar situation. I will implement this EEP in any case.