First of lot, let me say kudos for this binding! I was still stuck to FHEM for the enocean part of my setup, hopefully I can make the switch
I have a bunch of PEHA devices and have some troubles setting them up. Iāve manage to succesfully setup my roller-shutters, including feedback from the shutter about their position.
I do have some problems with the feedback from my PEHA D 452 FU-EBI OT switches. Via manual addition of the thing, I can switch the light by generating a A5-38 Central Command Thing using the proper IDs. Iāve tried the A5-11-03, PTM200 and A5-38-08 sub command 0x02 EEP for the receiving EEP, but unfortunatly no proper feedback is set on OH when I switch the light via another (physical) rocker.
This is what I see in the logs:
2018-10-22 15:44:23.357 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - RADIO_ERP1 with RORG _4BS for FFD3E302 payload A50000BF48FFD3E3020003FFFFFFFF2E00
2018-10-22 15:44:23.360 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet payload A50000BF48FFD3E30200 for FFD3E302 received
Hello Daniel (@fruggy83 ) and thank you for your respond.
After days of trouble i had resolved the problem tomorrow thanks to a power outageā¦
The Pi is under UPS, the NodeOn no. After the outage iāve started to see the RSSI of the relay. I think that these devices sometimes they could need (!!!) a power cycle.
I confirm that iāve not updated the binding nor added other sensors or devices. The relay is about 3 meters away from the usb bridge so i donāt think it was a distance problem. As i see a brutal, but effective, reboot of the relay had resolved the issue. Thank you a lot for the binding and your work, really.
(and the discovery problem could be related also to the erratic functioning of the relay)
@fruggy83 mmmh no the problem is still here: iāve tried to reboot the pi and then the same relay send null RSSI signal information. Iāve just remebered that the last week iāve accidentally unplugged the ups causing the reboot of the pi with openhabian (when the relay was still on)
I dont understand why rebooting the pi cause this issue. Where i had to look on the logs, by your experience?
I looked into the docs of your PEHA switch. I am sorry to say that this switch just answers with EEPs which are currently not supported yet. However I have already implemented parts of the D2-01 EEP. The needed D2-01-08 EEP should be really easy to implement. I should find some time tomorrow to do this. However as you maybe already read, I am trying to implement an official binding and do not want to further work on this older version of the binding. So if you want to be ahead of nearly everybody else, you should use the newer version of the binding from my other repo.
@fruggy83: thanks for your reply. I also did take a look at the docs of my PEHA device, it seems it is reporting using EEP A5-11-04 (Extended Lighting Status). Iām still a enocean noob and still have no complete picture how a datagram looks like, but from the small bit of information I think the interesting part of the payload are:
A50000BF48 for an OFF:
A5 4BS
00 (p1: 0 dimvalue)
00 (P2: 0 )
BF (P3: 191 hours (see below))
4(0100 -> normal mode,hours available, no error)
8(1001 ->Data telegram, 8bit dimmer + hours available, 0-> lighting off)
A5FF00BF49 for an ON.
A5 4BS
FF (p1: 255 dimvalue)
00 (P2: 0 )
BF (P3: 191 hours (see below))
4(0100 -> normal mode,mode 0: hours available, no error)
9(1001 ->Data telegram, 8bit dimmer + hours available, 1-> lighting on)
Seems to be consistent. @fruggy83: Do you need some help in development? Iām new to enocean and OH2 development, but Iām more than happy to help.
I am really sorry but currently I have no idee what happening there. This is really strange. If you have not done it already, you could activate the debug log of the binding in the karaf console by using the following command:
log:set DEBUG org.openhab.binding.openocean
Afterwards you will see every received message.If you receive a message without an item update, you could post this message (and the ones before and after) here, so I can analyse it further. I keep my fingers crossed.
@vince2k:
thanks a lot for your analysis. This looks really good If it is ok for you (and if you do not need the working hours of your lights) I would first start to implement the D2-01-08 EEP as I already implemented D2-01-09 and some other messages of this EEP family. Furthermore you are able to auto discover your switches with this EEP. However pull requests are always welcome
Thank you Daniel for the tip.
Here the result:
In my panel when i press ON and OFF a channel of the problematic relay:
2018-10-22 22:43:17.027 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived
2018-10-22 22:43:17.032 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 550009070156D2010101FF99F60500010508694BFF000E
2018-10-22 22:43:17.664 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D20461E40508694B00 for 0508694B received
2018-10-22 22:43:22.352 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived
2018-10-22 22:43:22.361 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 550009070156D2010100FF99F60500010508694BFF009A
2018-10-22 22:43:23.003 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D20461800508694B00 for 0508694B received
Here instead another relay (one that send RSSI information):
2018-10-22 22:45:01.846 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived
2018-10-22 22:45:01.863 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 550009070156D2010100FF99F6060001FFFFFFFFFF0070
2018-10-22 22:45:02.838 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D2046180050E7A2000 for 050E7A20 received
2018-10-22 22:45:02.854 [vent.ItemStateChangedEvent] - openocean_measurementSwitch_8eabb372_050E7A20_receivingState changed from Rssi 86, repeated 0 to Rssi 88, repeated 0
2018-10-22 22:45:15.023 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived
2018-10-22 22:45:15.026 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 550009070156D2010101FF99F6060001FFFFFFFFFF00E4
2018-10-22 22:45:16.246 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D20461E4050E7A2000 for 050E7A20 received
2018-10-22 22:45:16.268 [vent.ItemStateChangedEvent] - openocean_measurementSwitch_8eabb372_050E7A20_receivingState changed from Rssi 88, repeated 0 to Rssi 86, repeated 0
And here some messages i receive without item update:
from your last messages I can see that your switch also sends rocker switch messages (ESP Packet F6). Furthermore you have defined a rocker switch thing which reacts on these messages
So I am wondering if you really have defined a measurement switch thing with Id 0508694B or just a rocker switch thing? If your have defined a rocker and a switch, you should remove the rocker as I am not sure what happens if two things of different types have the same Id. Maybe just one of them receives the message in this case.
Hi Daniel (@fruggy83)
Just to be sure to use the same vocabulary:
Wall Switch: the switch wired directly to the actuator
Rocker Switch: a wireless wall switch based on Enocean protocol.
The latter i have 2 connected to the switch (one from one year or so, the other from 1 month, but the rssi worked after i connect the last to the relay)
The oldest one in made by NodeOn (Pink)
The newer is from Vimar and is a fancy and pricey version of the NodeOn but is the same āfamilyā of my wall switch, which is nice.
Attached you will find the PaperUi problematic relay (the 0508694B)
Iām totally aware of this. I think if I stood with openocean, you would have to merge all my PRs to the new repo, and I wouldnāt get all the new features Iām not dependent on a working binding, so consider me as a beta tester who can help fixing if something gets broken.
Let me show you the total usage history of one of my devices:
The value should never decrease, so the history is confusing and I think this is a problem. The question is if this is a problem of the binding, or a problem the user should care on his own. I tend to prevent this in the binding, since we know that these channels are channels where the value can only increase. A proposal how it could be done is on the way, I have to test it over the night first
The implementation of FWZ12 was very straight forward, since it uses the A5-12-01 EEP for Energy measurement:
automatedMeterSensor was not published to use, I did so and added that to the PR. From the documentation, it seems that the FUD61NPN uses an EEP similar to A5-38-08. Do you know if I can use your implementation āA5_38_08_Dimmingā for this? And, do you know which EEP I have to send to turn on the light alarm clock?
thanks a lot for your pictures. If you look at the channels of your relay ārele zona notte 2ā and your rocker switch āpulsante rosaā, you will see that both have the same ThingId (4th part of the channel id) 0508694B. However it is stated in the enocean docs that this Id is unique among all enocean devices. As my binding relays so deeply on this fact, you will get a problem as the binding cannot distinguish between your relay and rocker switch.
Each enocean message contains a SenderId, this is the EnOceanId of the sending device, which must be used as the ThingId of your openhab thing representing this device. The binding looks at this Id and searches an openhab thing with the same ThingId. The first found one will get the message and handles it. So it depends on the order of your thing definition, which message can be interpreted and which not.
The question is, are these Ids correct and how did you get them?
thanks a lot for your work, I will merge it after some slightly changes. However could you do me a favor and sign your commit. Without signing it, I cannot merge it into the official version of this binding (and mention you in the credits )
Thanks a lot for your understanding and your testing efforts. An automatic merge of your PRs is a lot of safer than my manual one (as you saw ). I hope to find some time to merge your PR in the next days and rearange the repo (adding a new dev branch)
The question is if this is a problem of the binding, or a problem the user should care on his own.
First of all I am very interessted in your proposal for this problem. But what do you think about to deactivate the polling of the energy data in your D2-01 NodOn thing? In this case you should only get the precise A2-12 values.
The implementation of FWZ12 was very straight forward
Glad to hear this. Maybe this could be an interessting holiday project
Do you know if I can use your implementation āA5_38_08_Dimmingā for this?
I am really sure that you can use this profile. If you look at this doc, you see that my FUD14 and your FUD61NPN use exactly the same EEP. I wish all manufacturers would provide such a good documentation.
And, do you know which EEP I have to send to turn on the light alarm clock?
I am not quite sure. Eltako sells a FSU14 which uses the A5-13-04 EEP. Maybe this EEP has to be teached into your FUD61. However if you look at the doc, you will see that the FSU14 also sends simple rocker switch messages (PTM200). Maybe you should try a genericThing with the switch channel in combination with a timer rule.
Thank you Daniel for your patience and the explanation!
I think iāve understand what is happen:
A year ago iāve provisioned all the modules in a test installation with the same usb c300 bridge (And ārele zona notte 2ā and āpulsante rosaā have been connected each other before the openhab setup). Then iāve done a full new setup, provisioning again the relay in a new openhab installation (but i didnāt reset them).
Maybe some relay had double adresses. Itās possible that they responded to the ON-OFF commands but not to send rssi information on newer ThingIDs? By the way, i didnāt experience any problem until the power goes out for the first time after months iāve done the first setup.
To be sure, iāve now reset every relay and provisioned them again in openhab: itās all working ok now, i get all the RSSI. signals.
I think one relay is a bit on the edge becouse i get rssi levels of 91-92, so iāve activated level 1 repeater for 2 relays near it and level 2 for the bridge (made it by multiple trials, without the level 2 for the bridge some commands didnāt reach the farther relay i donāt know why).
i re-installed your binding, link from your first post, but i still had to install the openhab-transport-serial.
Do i need to get the binding from a different link?
I am working on an official version of his binding. This version has some improvements over the openocean binding, which I do not migrate back.You find the newer version of this binding in my openhab/addons2 fork or wait until you can install it directly from within openhab.
That is really bad. I also have to use a repeater to get a stable connection to all of my switches. However I observed that to much repeaters made more problems than they solved. So I am currently using just one repeater.
Iād like to control a Sonos speaker in the bathroom with the Nod On CRC-2-6-01 Soft Remote (enocean items trigger sonos items via rules). Do you think this remote will work out of the box with your binding?