[Release] Generic Zigbee Drivers with Presence and Recovery

Announcement
The Generic Switch driver now support multi-gang Zigbee switches, such as the Nue Wall Switches.

There is now a Generic Zigbee Repair driver. It can be used to get the fingerprint of the device, clear Current State and Preferences as well as clean the Data section. It also has a command for removing all currently scheduled tasks for the current device.

EDIT: Added link to the Generic Zigbee Repair driver

3 Likes

Link added

1 Like

Hi @markus
Would it be possible to add the Tuya temp/humidity sensor to your zigbee drivers.
I believe it's zigbee 3.
Here is the info you require, I think.

  • endpointId: 01
  • application: 41
  • softwareBuild:
  • inClusters: 0000,0001,0402,0405
  • outClusters: 0019
  • model: TS0201
  • manufacturer: _TYZB01_a476raq2

Could you try my Sonoff Temp/Humidity Sensor with that one first? If it works as expected I can add the fingerprint there, they are very Generic, so maybe they should be renamed.

No joy I'm afraid.
It's no big deal but I like the presence capability that your drivers bring.

What do you get in the logs (with debug on) of my driver if you short-press the reset button on the Tuya sensor? The reason it doesn't work is likely because the configuration is only sent if the driver is already selected when pairing. That works well with Sonoff, but may need a change for the Tuya device.

Aha. It's working now. :+1:
Maybe it just needed a kick with the pair button
Here are the logs anyway in case there is anything in here that you may wish to look at.

That made the driver send the init calls, couldn't be sure the device would send the same packets, but it did, so all good :slight_smile:

1 Like

I'm afraid the device stopped reporting anything.
Reverted back to my old driver and it's kicked in again OK.

I have a number of XBee 3 Pro and one XBee XStick acting as repeaters. I've installed your Zigbee Repeater driver on them all. 2 of them are reporting as present - I get GENERAL CLUSTER EVENT in the logs. The others get errors says that checkin events have been missed. I did see "GENERAL CATCHALL (0x8038" in one log. Is there any particular XBee setting I need to be looking at? In my XBee settings I dont see anything that corresponds to Send Type set to Bind

I have also installed your Tasmota driver on a SonOff Dual - working fine, but has never become present. (I have hit configure, etc)

many thanks for all your work on these drivers - much appreciated.

I noticed that they dont appear as present/not present until an event occurs. This is standard. If you are worried, turn off your SonOff Dual (at the mains??) and see if it reports.

What's the old driver you use for that one? This really ought to work and should not be complicated to make the required changes for.

AP = API Enabled (1)
AO = Native (0)

With that it should work with using Bind requests to check for presence. Ping Type should be set to Bind. You could also also use MicroPython to add support for responding, but I've not used that so wouldn't be much of help setting that up.

If you use my version of Tasmota it should work. Do you get warnings in the logs about traffic not having a matching device? Please continue this part in the Tasmota thread :slight_smile:

Seemed to stop updating status, device page and dashboard.
The presence was happy.
Switched back to generic driver and working again.
Not sure what happened but here's some logs:

Sylvania Outlet (Osram) logs

@Ranchitat This was an unsupported type of status report, the next release has support for it and status will update as expected.

1 Like

This is now supported in the most recent Beta driver committed to the Repo today.

There are also many other updates to various drivers since when I make a change to one and that code is shared, it is updated in all of them.

Nue Dimmers are now supported with the Generic Dimmer driver.

@markus
Just tried your Dimmer driver on an Aurora Dimmer and it appears to be working OK. :+1:
His is the fingerprint/device info in case you want it.

  • endpointId: 01
  • application: 00
  • driver: v0.8.1.0718
  • endpointId: 01
  • profileId: 0104
  • inClusters: 0000,0003,0004,0005,0006,0008
  • outClusters: 0019
  • model: WallDimmerMaster
  • manufacturer: Aurora
1 Like

fingerprint model:"FB56-SKT17AC1.3", manufacturer:"Feibit Inc co. ", profileId:"0104", endpointId:"01", inClusters:"0000,0005,0004,0006,0702,0B04,0B01", outClusters:"0000"

Just tried the generic driver. I am having the above as a fingerprint.
I tried modify the driver with the above fingerprint and still the response from the outlet is very slow.

Thanks a tonne in advance,

Pugazhendhi M

Nice to hear, I've added this info as a fingerprint.

For those that do submit fingerprints in the future, please state the full model name/version and country it is for. Just so I know what is what in my files. Can get messy. Also, the best fingerprint format to supply to me is how it is reported by my Generic Zigbee Device Toolbox driver when you press Get Info.

Which generic driver? The Generic Outlet one?

The fingerprint is only used to select the correct driver when pairing a new device, it has no other function.

What do you mean by slow? Another driver is faster? What exactly doesn't update quickly? Would probably need logs and as much information as possible to know what is going on there. There is not yet support for multiple separate endpoints in the Outlet driver, only in the Switch driver. Is this a device that have multiple separately controllable relays?

For those that do submit fingerprints in the future, please state the full model name/version and country it is for. Just so I know what is what in my files. Can get messy. Also, the best fingerprint format to supply to me is how it is reported by my Generic Zigbee Device Toolbox driver when you press Get Info.

                            Company:   Panasonic
                             Model      :67200
                              Country :India

Yes @markus, I tried the generic outlet one.

sorry, I should be more clear on this. When I mentioned slow , it is the update with which the dashboard displays. The actual response from the device is not slow. I cannot say instant. But may be a one second response. Where as updates to the dashboard takes more than 2 minutes.

This is a single outlet plug.

For the logs, let me move the device back to the near vicinity of the hub and let you know.

Thanks for the quick reply.