Smanar / Domoticz-deCONZ

deCONZ plugin for Domoticz (Zigbee application)
GNU General Public License v3.0
36 stars 27 forks source link

Silvercrest Doorbell not working proberly #125

Closed xxLeoxx93 closed 2 years ago

xxLeoxx93 commented 2 years ago

Hey there,

I've issues getting this device to work in Domoticz. I can see the device, but no status change at all is transfered to Domoticz. Tbh not sure if this is an issue of deconz or of the addin, but when I press the doorbell it lights up in deconz node overview.

Thanks!

Error I see in the log when pressing it: `2022-02-17 16:45:10.019 Error: ConBee2: 'onMessage' failed 'TypeError':'int() argument must be a string, a bytes-like object or a number, not 'NoneType''.

2022-02-17 16:45:10.019 Error: ConBee2: Exception traceback:

2022-02-17 16:45:10.019 Error: ConBee2: ----> Line 938 in '/home/pi/domoticz/plugins/Domoticz-deCONZ/plugin.py', function onMessage

2022-02-17 16:45:10.019 Error: ConBee2: ----> Line 240 in '/home/pi/domoticz/plugins/Domoticz-deCONZ/plugin.py', function onMessage

2022-02-17 16:45:10.019 Error: ConBee2: ----> Line 786 in '/home/pi/domoticz/plugins/Domoticz-deCONZ/plugin.py', function WebSocketConnexion

2022-02-17 16:45:10.019 Error: ConBee2: ----> Line 700 in '/home/pi/domoticz/plugins/Domoticz-deCONZ/fonctions.py', function ButtonConvertion`

Smanar commented 2 years ago

Ha yes, this issue is not new.

Can you try with the beta version ?

git pull
git checkout beta
git pull
xxLeoxx93 commented 2 years ago

Do I've to readd the device in deconz first? I'm up to date with the beta now, restarted Domoticz and Re-Added the switch in Domoticz. Now I can see the battary level, but no button press is reported. Error in logs are gone!

Smanar commented 2 years ago

Do I've to readd the device in deconz first?

No, I don't think if you can see it, for me it's fine

Now I can see the battary level, but no button press is reported.

Arf not good, you don't see event log about websocket in domoticz logs ? Mean the device is perhaps not supported ATM. What is your deconz version ? your manufacture name is _TZ1800_ladpngdx ?

Ok bad luck, lot of lidl tuya device are broked ATM https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5702

xxLeoxx93 commented 2 years ago

Manufacturer is reported as LIDL Silvercrest, model is TS0211. When I press it I don't see any message in the Domoticz Log. Do I've to change the logging somewhere?

Smanar commented 2 years ago

Nope, you can use the tab in domoticz / custom / deconz / sensor to have the real manufacture name. This one is modified by the core to "LIDL Silvercrest" so no way to reconize it now with the bugged model id.

But I think it s the _TZ1800_ladpngdx

The PR is not validated, so if you realy want to use this device, you need to use an older deconz version, or can compile the code yourself. I can explain you how to do, you just need to use a full Unix machine with complete OS for deconz. The operation don't break your settings.

xxLeoxx93 commented 2 years ago

This is what I see there: image So it should not be affected by this issue?

Smanar commented 2 years ago

I think it's. According to this capture https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4260 you have exaclty the same value for the firmware, you have not "_TZ1800_ladpngdx" as model id in the API because of a bad idea, but if you take a look direclty with deconz I m sure you will see this model id.

xxLeoxx93 commented 2 years ago

Even there it shows "Lidl Silvercrest": image Maybe a new version? Anyways assuming it's affected now I can either wait until a fix is implemented, compile a custom version myself or revert to an earlier deconz version right?

Smanar commented 2 years ago

Maybe a new version?

He ? Honestly, first time I see this one .... I have just made a check, on google I nerver see at least one device with the manufacture name "LIDL Silvercrest" But yes, in the actual code, this device can't work.

And if this "strange manufacture" name is not caused by API code, you will need more modification on code, but the problem is how to reconize the device, there is plenty device with model id "TS0211" and seriously I think it will be same for ""LIDL Silvercrest"" as manufacture name.

I will ask to other devs if it's something normal for them.

And if you want to compile the code, if you have a full OS with unix system I can give you the line to type.

xxLeoxx93 commented 2 years ago

Thanks for the offer! I've a second RPI with Debian - does that work?

Smanar commented 2 years ago

The compilation is device dependend, so lot of chance it don't work if you compile it on a pi4 to use it on a pi 3. What is the machine (and the OS) on the host where deconz is running ? But yes debian is fine.

xxLeoxx93 commented 2 years ago

They are identical :) What do I need to do? Thanks again for your support! I can also compile it on the raspberry that runs deconz.

xxLeoxx93 commented 2 years ago

BTW: I I just realized that if you use if devicechanged['KlingelLidl'] then in a script it already works. Seems like only once every 24h, but in fact the script will triger then.

Smanar commented 2 years ago

But can just be battery update ?

You have the procedure here https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Compiling-the-REST-plugin-for-device-specific-testing So for you, after having installed deconz (The code is based on realy last one, so need a recent version):

sudo apt install deconz-dev
git clone --branch switch_issue_1 https://github.com/Smanar/deconz-rest-plugin.git
cd deconz-rest-plugin
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

If you have a small raspberry, it can freeze during compilation, my pi 3 do, so remove "-j2"

It don't impact your zigbee database, but can use a lot the CPU (at least the first time, compilation will be faster after). To rollback fastly you can make a backup of the file /usr/share/deCONZ/plugins/libde_rest_plugin.so in another folder

and bad news you need too replace the json file /usr/share/deCONZ/devices/button_maps.json by this one https://github.com/Smanar/deconz-rest-plugin/blob/switch_issue_1/button_maps.json Or just edit it, you have the change here https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5702/files

And I think you will probalby need to re-include the remote too.

If you realy have a new model (I still have no return about your manufacture name) all will be in place for a new corrective, so will be faster.

You can too compile the file on a machine and copy the file libde_rest_plugin.so on the second one. The compilation change only this file, but will not work if you have a 6 month older deconz version.

xxLeoxx93 commented 2 years ago

Thansk a lot! Before I go ahead and do this: Will the next deconz update overwrite this (or already include this fix?)?

Smanar commented 2 years ago

Good question. You have the PR here https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5702 you can check if manup validate it.

ATM PR on code are locked https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5733 But can be validated if its a fix.

Some PR are in waiting list since 4/5 months, so no way to be sure this one will be validated.

xxLeoxx93 commented 2 years ago

Sorry for my late feedback. Due to an issue with my pi I had to do a complete resetup, now running docker. Since this isn't super urgend for me and I've spend now enough time with my pi ( :P ) I'll just wait and hope that it will be fixed soon. Thanks a lot for your help!

Smanar commented 2 years ago

NP, and the PR is not yet validated. I think the DDF will support battery switch before this PR will be validated/deleted.

cwm77 commented 2 years ago

Hi, is it already foreseeable when the DDF will be implemented for this device?

Smanar commented 2 years ago

Ha yes, there is so much issue, so idk if all can be solved but yes can make a try. What is your device ? Can you share at least a DDF squeleton ? (with basic cluster identification and one ZHAswitch) ?

cwm77 commented 2 years ago

Ha yes, there is so much issue, so idk if all can be solved but yes can make a try. What is your device ? Can you share at least a DDF squeleton ? (with basic cluster identification and one ZHAswitch) ?

Hey, thanks! The device is the in this thread mentioned SILVERCREST Doorbell HG06668.

Bildschirmfoto 2022-05-18 um 18 37 18

I own it and could share the DDF selection. Should I post it here?

Smanar commented 2 years ago

So it's the _TZ1800_ladpngdx ?

Sure, you can c/c the DDF here.

cwm77 commented 2 years ago

Yes, it is. Here is the DDF. Can you do something with it? Unfortunately, it looses its json format while coping it here. If you like, you can download it here. https://cloud.weilba.ch/s/rcapBGRggmtJQcG

{ "schema": "devcap1.schema.json", "manufacturername": "_TZ1800_ladpngdx", "modelid": "TS0211", "product": "TS0211", "sleeper": false, "status": "Draft", "subdevices": [ { "type": "$TYPE_SWITCH", "restapi": "/sensors", "uuid": [ "$address.ext", "0x01", "0x0500" ], "fingerprint": { "profile": "0x0104", "device": "0x0402", "endpoint": "0x01", "in": [ "0x0000", "0x0001", "0x0500" ] }, "items": [ { "name": "attr/id" }, { "name": "attr/lastannounced" }, { "name": "attr/lastseen" }, { "name": "attr/manufacturername" }, { "name": "attr/modelid" }, { "name": "attr/name" }, { "name": "attr/swversion" }, { "name": "attr/type" }, { "name": "attr/uniqueid" }, { "name": "config/battery", "description": "The current device battery level in 0–100 %.", "default": 0 }, { "name": "config/enrolled", "description": "State of IAS enrollment process." }, { "name": "config/on" }, { "name": "config/pending", "description": "Pending tasks to configure the device." }, { "name": "config/reachable" }, { "name": "state/buttonevent", "description": "The last received button event." }, { "name": "state/lastupdated" }, { "name": "state/lowbattery", "description": "True when the device battery runs low." }, { "name": "state/tampered", "description": "True when the device tampered alarm was triggered." } ] } ] }

Smanar commented 2 years ago

Ok so this one will be the easier, it s the other that have the broadcast issue.

Can you try this DDF

{
  "schema": "devcap1.schema.json",
  "manufacturername": "_TZ1800_ladpngdx",
  "modelid": "TS0211",
  "product": "TS0211",
  "sleeper": true,
  "status": "Gold",
  "subdevices": [
    {
      "type": "$TYPE_SWITCH",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0500"
      ],
      "fingerprint": {
        "profile": "0x0104",
        "device": "0x0402",
        "endpoint": "0x01",
        "in": [
          "0x0000",
          "0x0001",
          "0x0500"
        ]
      },
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/battery",
          "description": "The current device battery level in 0–100 %.",
          "default": 0
        },
        {
          "name": "config/enrolled",
          "description": "State of IAS enrollment process."
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/pending",
          "description": "Pending tasks to configure the device."
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/buttonevent",
          "description": "The last received button event."
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0001",
      "report": [
        {
          "at": "0x0021",
          "dt": "0x20",
          "min": 60,
          "max": 3600,
          "change": "0x00000001"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0500"
    }
  ]
}

Then if you go in deconz / help / debug view, with the flag "info" and "info_l2", you will see error when using it.

So edit the button_maps.json file (in /usr/share/deCONZ/devices) and add

       "lidlDoorbellMap2": {
            "vendor": "Tuya",
            "doc": "Lidl / Silvercrest doorbell (_TZ1800_ladpngdx)",
            "modelids": ["_TZ1800_ladpngdx"],
            "buttons": [
                {"S_BUTTON_1": "Button"}
            ],
            "map": [
                [1, "0x01", "IAS_ZONE", "STATUS_CHANGE", "0x01", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Ring"]
            ]
        },

It will solve some error message but I think we still have one because of this part

                   else if (zclFrame.commandId() == 0x00 && zclFrame.payload().size() > 3 && buttonMap.zclParam0 == zclFrame.payload().at(0))
                    {
                        ok = true;
                    }

I m waiting your confirmation to correct it, the better will be with editing code, but can be done using DDF too. Remeber this device need a IAS enrollement, so can take some time.

cwm77 commented 2 years ago

Thanks, i can see now

[INFO] - Button 1002 - TS0211, unicast to: 0x0000, endpoint: 0x01, cluster: IAS_ZONE (0x0500), action: Ring, payload: 010000640000, zclSeq: 9

in the debug view, if I press the bell button. Before I had

[INFO] - No button handler for: TS0211, unicast to: 0x0000, endpoint: 0x01, cluster: IAS_ZONE (0x0500), command: STATUS_CHANGE (0x00), payload: 040000640000, zclSeq: 9

I'm using HA. I reloaded there the deconz integration, but a new ringing entity didn't appear yet.

Smanar commented 2 years ago

Its the first time you are using this device, or you already use it before the issue ?

Because It seem we don't need more code. The payload is too long 01 00 00 64 00 00 but it still working because the code for the Samjin button

You can check in phoscon / help / Api information / events, I think you will see the "buttonevent" value updated in the device json.

Now, how to use it in HA is another question, you don't have something called buttonevent ? (you will no see "ring" it s like a simple switch)

cwm77 commented 2 years ago

I have tried to integrate this device before, but the bell button did not work then. Now it works and I also get an event id 1002. With this, it is possible for me to filter within HA and trigger an action. So this works now, thank you. Can it be that the adjustment to button_map alone was enough?

Smanar commented 2 years ago

Easy to check. The code use fake lidl name instead of the real model id, so look the device model id and the manufacture name in the api if it's _TZ1800_ladpngdx and TS0211, it's because the DDF if it's HG06668 or TS0211 and LIDL Silvercrest , it's because of the code issue, and the device can't work, we need the real manufacture name _TZ1800_ladpngdx

If all is working, I will make a fast PR for it.

And BTW , as they are using same code I will mix the 2 buttons map like that

        "lidlDoorbellMap": {
            "vendor": "LIDL Silvercrest",
            "doc": "Lidl / Silvercrest doorbell (_TZ1800_ladpngdx)",
            "modelids": ["HG06668","_TZ1800_ladpngdx"],
            "buttons": [
                {"S_BUTTON_1": "Button"}
            ],
            "map": [
                [1, "0x01", "IAS_ZONE", "STATUS_CHANGE", "0x05", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Ring"]
            ]
        },
Smanar commented 2 years ago

So no issue on your side ? I can make the PR @cwm77 ?

cwm77 commented 2 years ago

Sorry for my late answer. Yes, there are no issues so far. Thank you for your effort.

Smanar commented 2 years ago

PR merged officialy