HomeMatic IP Request: Add NEW HmIP DLD Door Lock

Feature Requests
16

Nice work. :+1:

May I ask if you have tried to use the homematic.set_device_value service (for locking and unlocking) I have mentioned above? That way you wouldn’t have to use the program in the CCU, just the variable for the status. Note, that I don’t know if what I have suggested above actually works. I just assume it might based on how the parameter (LOCK_TARGET_LEVEL) is defined in the paramset description.

17

Thx.
The crazy thing is that the device does not appear in honeassistant. There is no entity created. When I have some time early next week I will post my integration config. I might miss sth. If that would work the solution would be much smarter!

18

If you have any HomeMatic devices visible, then you should also have the homematic.*-services. That’s not an entity, it’s the domain where the integration provides the services for manual usage.

19

can you give a hint, where those “service” should have to go ?

does address,channel, param, value go to data-section of a service definition ?
into configuration.yaml…
the service set_device_value is mentioned in homematic doku on hass.io, but under action…
Everything I do leads to “there is a configuration error”… It would be helpful to show (and appreciated) what you put where (as snippets) to make it work ?

Maybe this way:
e.g.:
configuration.yaml

service: homematic.set_device_value
  data:
     address: serial
     channel:1
     param: LOCK_TARGET_LEVEL 
     value: open

(the dokus miss always the part, what this is, what they are talking about… they throw a lot of words and params into a bowl, and never explain what it is… e.g. “address”… in the examples (homematic) there is always LEQ123456… how one can conclude from that, that this should be the SerialNo of Device… all devices of homematic have a MAC-address looking SerNo, why there is a “LEQ”-Prefix in the example? they should mention it, what the param means - very hard and very very frustating to come to an understanding by reading docs if the crafted that way)

20

I assume this is what your template-lock should look like:

lock:
  - platform: template
    name: Basedoor
    unique_id: basedoor
    value_template: "{{ states.homematic.ccu2.attributes.base_lock_status }}"
    lock:
      service: homematic.set_device_value
      data:
        address: 0011223344...
        channel: 1
		param: LOCK_TARGET_LEVEL
        value: 0
    unlock:
      service: homematic.set_device_value
      data:
        address: 0011223344...
        channel: 1
		param: LOCK_TARGET_LEVEL
        value: 1

That’s how the serials of the old HomeMatic devices looked like. The MAC-like addresses were introduced with HomeMatic IP. And back then when we started the HomeMatic integration (and documentation) the old devices were what the users primarily had. So to those people it was clear what this placeholder was referring to.

2 Likes
21

I tested it and it worked:)
I can confirm that set_device_value is working with the mentioned values.
That way it is much leaner - in addition to the lock template in HA, i now just have the status variable and a program setting the status var.
I just recognized, that changing the status in HA after pressing lock or unlock needs 10-20 seconds - any idea where this could be improved?

2 Likes
22

Nice. You should consider adding your solution as part of the documentation so others can easily recreate it. :+1:

23

Did it and created a pull request. Never did use github before, so i hope i have maintained everything needed.

24

Thanks @tobiasm for your solution and also thanks to @danielperna84 for his nice wrap-up. :clap:

After some fiddling around, I managed to get all up and running by

  1. adding daniels template into configuration.yaml,
  2. creating a status variable in homematic,
  3. creating a program in Homematic (see attached screenshot)
    (which sets the value of the status variable to ‘LOCKED’ and ‘UNLOCKED’, respectively - which is kind of counter-intuitive, as the values send from home assistant to homematic are ‘0’ and ‘1’ :roll_eyes: ) , and finally
  4. creating a script to use DLD’s ability to “open” the door be holding the latch for a short period of time.

Interestingly, I had to explicitly code the value_type to int! Otherwise it didn’t work… :man_shrugging:

value: '0'
value_type: int

Bildschirmfoto 2021-09-10 um 22.37.05
Bildschirmfoto 2021-09-10 um 22.37.05716×415 44 KB

2 Likes
25

Hi,

picking up this older one.

@danielperna84, one of the latest updates to your HA lib seems to have an addition to show the lock status as a sensor.

I have the DLD at home now. That sensor does not show up, only battery status.

Is this not included into latest HA release yet or am I doing something wrong?

Cu!

1 Like
26

Great! Any chance to get this also processed for the HMIP Access Point integration? I‘ve raised already a pull request but it has beeb closed as i giess i mossed something:-(

Would be so great to have it also integrated straight with the HMIP AP .
Any chance i can support in it? Thanks!

2 Likes
27

I have created a PR that should fix the issue. :+1:

28

Tested the PR. Works!

Great. No HMIP Variable Hack and program needed anymore. :slight_smile:

29

THX: I´ve raced this feature also. no solution till now? (same for other kits from ELV - like the 2-temperature sensor)

30

I will post the solution as soon as the next release includes the fix. It only enables DLD to be used easier.

32

I’d love to see a better integration of HmIP DLD without a CCU2/CCU3 as well… hoping with you

33

The HMIP DLD lock and the HMIP AP are working great in Homekit via the integration plugin from marc sowen: HOOBS

I switched cause of the plugin from
HA to hoobs and need to admit it‘s working great.

34

Documentation update, still pending to get merged.

35

Hi,

sorry for this stupid question: But is it possible to create a switch out of the DLD Lock_state entity?
I want to lock & unlock my dld via a homeassistant button.
many thanks in advance

36

Link on how to integrate HMIP-DLD.

1 Like