Trying to add D2-50-00 via EEP and mapping #98
-
|
Hi, need some help debugging my attempts to add some support for D2-50-00. Currently getting following traceback from the eep.py: Now i want to change the eep.py to add some logging and see what is really happening, but all attempts to rewrite the python files and restart the container erased all the changes inside the container. This is the packet causing the error: This is the EEP.xml change: This is the mapping.yaml change: How can i debug this further? |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 5 replies
-
|
Hi @billeranton, I am working on it so good that you are available for testing 👍 I suspect your xml for D2-50-00 is incomplete and there are may be some errors. Also, the mapping is incorrect as the command shortcut used in D2-50-00 is 0xD2:
0x50:
0x00:
device_config:
command: "MT"
channel: "MT"
log_learn: ""
direction: ""
answer: ""
entities:
- component: "sensor"
name: "temperature_outdoor"
config:
state_topic: "MT2"
value_template: "{{ value_json.OUTT }}"
device_class: "temperature"
unit_of_measurement: "°C"
- component: "sensor"
name: "temperature_indoor"
config:
state_topic: "MT2"
value_template: "{{ value_json.INT }}"
device_class: "temperature"
unit_of_measurement: "°C"
If you still want to change eep.py, please have a look at this page in the wiki. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, @mak-gitdev Is it now possible that this second radio packet should be matching the 0x3 "Ventilation extended status" in the EEP.xml? |
Beta Was this translation helpful? Give feedback.
-
No. If you look carefully at the log, you will see that a second packet is received with type 3: There is an error because the last 10 bytes of that packet are set to 0 but the current EEP.xml doesn't support this case. Please use this new file instead. |
Beta Was this translation helpful? Give feedback.
-
|
Very nice, now all the values can be read out for message type 2 and 3. For example here: No crashes 👍 Am also able to send commands: mapping log Here the full log: The only problem currently is, that both devices react to the DOMC/OMS change. During "learning/teach in" I have assigned one to channel 1 and the second one to channel 2, on the devices themselves. Not sure if this has to be reflected somewhere in the mapping, or the issue lies somewhere else. In the above example home assistant is sending "Level 4" to one of the two, but both report back immediately with the new OMS value "Level 4". Before sending "Level 4" one was on "Level 2" and the other on "Level 3". Just if someone searches for specific device support, the devices tested here are Glen Dimplex DL 50 WE2. Software Version 21.6. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @billeranton, Nice !
As I don't know how these devices work, could you please give more details about what you call channel 1 and channel 2 ?
Does this happen every time you send a command to one of the devices ? |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the channels, the manual mentions that you can assign at max 5 enocean components to a device. e.g. a switch, a sensor or a gateway/home-automation-system. For each assignment you would use up a channel on the device C1...C5 during teach-in. So on one device before teach-in, I selected C1 (channel 1) and started the teach-in/learn. Then the device shows on its display the successful assignment via Y1, instead of C1. Same for the second device. C2 -> Y2. But yeah, every time all the commands are received by both devices. I think i will have to unlearn all of them an try different constellations to be entirely sure. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, marked it as answered, since the basic support for the profile works now. Regarding this issue, where both devices answer to a command i have attached log files. But no solution currently. In this scenario, there is currently one one device mapped in the devices file (to rule out any hassio mapping interfering): Then added the second device (via learn button in ha and the 'rc' menu in the device) (11:55:28,404). Then changed the operating mode to 'level 4' -> 'DOMC: 4' (11:56:26,096), and finally received the answer from the second device (11:56:26,847) which unfortunately also was changed to 'level 4'. Now, out of obvious options, still, thank you for your great support! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @billeranton, I think I just understood what is happening. The EEP D2-50-00 doesn't define a channel id in the commands. The solution should be to pair the dimplex with different sender id. Unfortunately, this is not yet available as the |
Beta Was this translation helpful? Give feedback.
-
|
Hi, yes this makes totally sense. There is the same topic discussed here Implement fetching of module ID regarding the base library. The device in question is a HVAC device, which is kind of similar in a broader sense. As far as i understood it, if you take older or more simpler devices like a button into account, the button for example cannot know the target address during teach in, only the target learns about the buttons sender address. So this fits the hypothesis to separate by sender address. The only thing that bugs me, is that the Dimplex device knows it is paired to a gateway (displays letter Y for gateway instead of X for simple pairing to e.g. button). So it should behave accordingly, but eventually does not. Hope you find a way to include the sender address. |
Beta Was this translation helpful? Give feedback.
@billeranton,
No. If you look carefully at the log, you will see that a second packet is received with type 3: