[SUGGESTION] Team up with "Zigbee for Domoticz" developers who is developing a zigpy based plugin for Domoticz about deconz-serial-protocol HOT 41 OPEN

@manup If dresden-elektronik / Phoscon would help sponsor them with hardware by donating a few of your ConBee USB sticks and RaspBee Raspberry Pi Shields to @pipiche38, @badzz @SylvainPer and @jp-keros

Hi @Hedda great to hear that zigpy is growing. We can send free samples to the developers, I only need shipping addresses send to [email protected] (just reference me and this issue).

Again, as I understand it, zigpy, bellows, Domoticz, and this new "Zigbee for Domoticz Plugin" are all only spare-time hobby projects but still, I think that teaming up might give all involved projects some more positive recognition in the Domoticz community and the whole home automation scene in general which might attract more developers and willing alpha/beta-testers from the community to come to help out with all these involved projects which in the long run could benefit all users wanting Zigbee in Domoticz to become more mature and working with more Zigbee hardware dongles than it is today.

Indeed I think this brings benefits like projects using zigpy don't have to fully reinvent and maintain all the Zigbee complexity on their own and join forces.

from deconz-serial-protocol.

mail sent to @manup .

from deconz-serial-protocol.

Thanks for the mail the samples should arrive quickly :)

• Not possible to form a new network and to change the Extended PAN Id ( a must for Legacy Wiser devices)
• Not possible to add coordinator Endpoint as for ZNP or Ezsp (for exemple) this prevent having
  Wiser legacy and Wiser paired and working Livolo switch

The serial protocol allows to specify Extended PANID ("APS Use Extended PANID" parameter) and to configure custom endpoints/clusters. These need be set while the network is disconnected and become active after network start.

from deconz-serial-protocol.

thanks @manup , that was more less my understanding, just need to get that implemented on the zigpy-deconz side.

from deconz-serial-protocol.

Thanks for the mail the samples should arrive quickly :)

Big thanks for the sponsorship @manup , will keep you posted.

from deconz-serial-protocol.

Looks to me like the is "deCONZ_Rpi" firmware images for it here -> https://deconz.dresden-elektronik.de/deconz-firmware/

deCONZ_Rpi-latest.bin.GCF is today currently the same as deCONZ_Rpi_0x26400500.bin.GCF from 18-Aug-2021 21:43

So assume that "deCONZ_Rpi" firmware images is for "old" first-generation shield and "deCONZ_RaspBeeII" is for RaspBee II?

As I understand the application firmware feature and function parity is the same for the first/old RaspBee and new RaspBee II?

Believe that the only relative practical difference is that the RaspBee II hardware has a newer radio chip MCU model == better?

from deconz-serial-protocol.

From feature perspective RaspBee I and II are comparable, with the difference that the 1. gen also implements the unholy Touchlink function. RaspBee I doesn't use NXP but Atmels (now Microchip) ATmegaRFR2, the R21 chip in RaspBee II is newer, but this makes no real difference for Zigbee, both have a power amplifier (PA) and low noise amplifier (LNA) to strengthen sending and receiving. The next gen is based on Silabs and will also use the same serial protocol.

@manup could you kindly clarify which API needs to be use to configure custom endpoints/clusters that ?

To configure the endpoints the parameter 0x13 need to be written via WRITE_PARAMETER (0x0B) request. I just noticed this is currently missing in the docs, I've put it on the todo list.

Example: simple endpoint

The following configures endpoint 0x01 as first endpoint at index 0x00.

U8   0x0B    // CommandID: Write Parameter
U8   0x01    // Sequence number
U8   0x00    // Reserved
U16  0x0017  // Frame length (7 + Payload length = 23)
U16  0x0010  // Payload length (1 + Length of Parameter = 16)
U8   0x13    // Parameter ID

// Parameter payload: Simple Descriptor of the endpoint

U8  0x00     // Index (3 endpoints are supported: 0-2)
U8  0x01     // Endpoint
U16 0x0104   // HA Profile ID
U16 0x0005   // Device id: Configuration Tool
U8  0x01     // Device version
U8  0x02     // Number of server clusters
U16 0x0000   // Basic server cluster
U16 0x0019   // OTA server cluster
U8  0x01     // Number of client clusters
U16 0x0500   // IAS Zone client cluster

Note that the U16 values need to be written as little endian byte order 0x0019 → 0x19 0x00.

Hope that helps.

from deconz-serial-protocol.

Providing certain clusters is necessary for a few devices which query the coordinator for these via Match Descriptor Request. The actual ZCL cluster implementation is done in the application. The OTA, Time and IAS clusters are a good choice to handle a wide range of devices.

For example many Xiaomi devices query the coordinators Time cluster and act up if they don't receive an response.

Here is the default configuration that deCONZ currently sets:

The default endpoints which are initially set by the firmware depend on the firmware version, I think it contains Basic, Time and OTA. For that reason we check in deCONZ if everything needed is configured and extend the cluster list if necessary to be independent of the firmware version in use.

The endpoint 0xF2 is needed if you want to support Zigbee Green Power Proxy support.

from deconz-serial-protocol.

Quite interesting here is the OpenThread stack which we'll support also for ConBee II / RaspBee II as Border Router. It has configurable architecture and allows the radio firmware to be simple and out source the heavy parts to the host application.

FYI, I understand Silicon Labs FW in "RCP" mode (instead of "NCP" mode) can also offload parts of their Zigbee stack to host, see:

zigpy/zigpy#894

It basically moves large parts of the application stack (Zigbee/OpenThread stack) to the "host" CPU. In practice, it means that e.g. the Zigbee implementation runs as a daemon on Linux (named zigbeed). The daemon then talks regular EZSP/ASH protocol to higher level applications (such as zigpy), and talks via another daemon called cpcd (Co-Processsor Communication daemon) to the firmware running on the Silabs radio.

https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol

from deconz-serial-protocol.

Thanks @Hedda for that, but I wonder what would be the benefit of such integration while there is already a deConz dedicated plugin for Domoticz available https://github.com/Smanar/Domoticz-deCONZ . Maybe @manup you could give your point of view ?

I also don't see much activity on the zigpy-deconz github , does that mean it is mature and stable ?

accept my naive question, but is the serial protocol available on all deConz firmware version, or is that only available on specific one ?

from deconz-serial-protocol.

Thanks @Hedda for that, but I wonder what would be the benefit of such integration while there is already a deConz dedicated plugin for Domoticz available https://github.com/Smanar/Domoticz-deCONZ . Maybe @manup you could give your point of view ?

To compare situation there was already deCONZ dedicated plugins/integrations for Home Assistant and Jeedom before their zigpy based implementations came to be and now there are many users of those that use ConBee and RaspBee adapters with them.

Also note that today it is no longer only Dresden Elektronik's official deCONZ/Phoscon application and the zigpy based integrations like Home Assistant's ZHA integration component and Jeedom's Zigbee Plugin that has native support for ConBee and RaspBee adapter via this deconz serial protocol, but also zigbee-herdsman based projects like Zigbee2MQTT and IoBroker as well. Both the Zigbee2MQTT developers and developers of the zigpy based Jeedom Zigbee Plugin are listing ConBee II adapters to their users. See https://www.zigbee2mqtt.io/guide/adapters/#recommended and https://doc.jeedom.com/en_US/plugins/automation%20protocol/zigbee/ and https://www.home-assistant.io/integrations/zha

Supporting an additional hardware type would of course mean more work but I believe that there could be several different good reasons and benitis with your zigpy based implementation also supporting ConBee and RaspBee adapter via zigpy-deconz;

• Supporting an additional Zigbee Coordinator adapter type should open up to a broader userbase and more users of a project could indirectly eventually lead to more developers joining your project.
• Users wanting to migrate from Dresden Elektronik's official deCONZ/Phoscon application to your Zigbee for Domoticz Plugin does not need to buy new hardware to test your plugin.
• Chaos engineering theory suggest that experimenting with support for separate types of hardware from different manufacturers should give you a better insight and lead to the discovery of more bugs or possible design flaws that can then be solved to achieve an overall more stable result in the end. https://en.wikipedia.org/wiki/Chaos_engineering

I also don't see much activity on the zigpy-deconz github , does that mean it is mature and stable ?

Yes the zigpy-deconz library should be considered mature and stable which is the main reason why there are not many updates for that GitHub repository. Jeedom developers is even listing it as the foremost recommended adapter for their implementation before any other adapters -> https://doc.jeedom.com/en_US/plugins/automation%20protocol/zigbee/

deconz based adapters are still also listed at the top of the compatibility list for Home Assistant's ZHA integration (however I do not believe that any of the zigpy developers that are most active today are currently using ConBee/RaspBee adapters in their own personal "main-production" Zigbee setups) -> https://www.home-assistant.io/integrations/zha

is the serial protocol available on all deConz firmware version, or is that only available on specific one ?

All deconz firmware versions are supported by zigpy-deconz but it is highly recommend that users first update their ConBee/RaspBee adapters to the latest deconz firmware to avoid bugs that have been fixed in newer firmware releases, see- > https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Firmware-Changelog

from deconz-serial-protocol.

@Hedda thanks , but as already reported there are some issues which seems to be only fixed on the new-radio-API which looks for me and for the Zigbee for Domoticz plugin and handicap.

• Not possible to form a new network and to change the Extended PAN Id ( a must for Legacy Wiser devices)
• Not possible to add coordinator Endpoint as for ZNP or Ezsp (for exemple) this prevent having
  Wiser legacy and Wiser paired and working
  Livolo switch

Anyway I have sent an email to @manup (as mentioned earlier).
I would use Jeedom as a reference as they have a closed system and do not share their source code.

from deconz-serial-protocol.

@Hedda thanks , but as already reported there are some issues which seems to be only fixed on the new-radio-API which looks for me and for the Zigbee for Domoticz plugin and handicap.

• Not possible to form a new network and to change the Extended PAN Id ( a must for Legacy Wiser devices)
• Not possible to add coordinator Endpoint as for ZNP or Ezsp (for exemple) this prevent having
  Wiser legacy and Wiser paired and working
  Livolo switch

Anyway I have sent an email to @manup (as mentioned earlier). I would use Jeedom as a reference as they have a closed system and do not share their source code.

@manup @pipiche38 So I understand that all those are functions that do already exist in deCONZ Serial Protocol but they have not yet been added to zigpy-deconz so should be feature request or pull requests for https://github.com/zigpy/zigpy-deconz/ ?

from deconz-serial-protocol.

the Extended PAN Id seems to be implemented in the new Radio Api, however the force_form new network I have issues with.

For adding Ep, I didn't find any api for that (probably because we are the only one having Schneider Wiser eco-system running)

from deconz-serial-protocol.

I would use Jeedom as a reference as they have a closed system and do not share their source code.

@pipiche38 That is not completley true. Jeedom developer @zoic21 explained that do share the source code of the plugin but not directly via a Git repository and instead just to those who bought their Zigbee plugin via the Jeedom Market, which while maybe is not in the spirit of FOSS (Free and Open Source Software) is technically allowed according to the GPL license used. However since you can not simply download the Jeedom plugin from a Git repository they do make you jump through some hops to get the source code, as instead you need to first install Jeedom and register account for their Jeedom Market, then buy and install the Zigbee Plugin from their Jeedom Market, after that the plugin can be installed on your computer. As the plugin is coded in Python it is also source code and as such it is now available to you on your local computer from the installation directory:

https://www.jeedom.com/market/index.php?v=d&p=market_display&id=4050

[EDIT]: Update! Re-posted this @zoic21 Git repo request for Jeedom Zigbee plugin source code to here -> zigpy/zigpy#725

PS: I do not personally agree with their practice of having a partially closed system which do not make code directly available via Git to other developers as I believe in the spirit of FOSS (Free and Open Source Software) when depending on other projects code, so in the spirit of open sourcve I think that they should instead have them put their Zigbee Plugin in a public GitHub repository under https://github.com/jeedom as they have done with Jeedom itself and other plugins for Jeedom so that developers from other projects like yourself could take advantage by learning from their implementation without having to buy their plugin and install the software. That would allow all developers and projects depending on zigpy to collaborate much easier.

from deconz-serial-protocol.

@manup I tried to use the old RasBee shield you sent to me 2 years back. Unfortunately I'm not able to make it running

The ConBee II works fine. I have been able to update to the latest firmware.
For the RasbBee it looks like there is firmware for RasBee II but not RaspBee. Does that means this version is not supported ?

sudo GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------
/dev/ttyACM0     | 0x1CF1 | 0x0030  | DE2227699  | ConBee II
/dev/ttyAMA0     | 0x0000 | 0x0000  |            | RaspBee

Here after is the zigpy error I'm getting

2022-03-15 18:01:22,265 WARNING :No response to 'Command.read_parameter' command with seq id '0x02'
2022-03-15 18:01:22,275 ERROR :Error Traceback (most recent call last):
File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppDeconz.py", line 60, in startup
    await super().startup(auto_form=auto_form)
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/zigpy/application.py", line 61, in startup
    await self.connect()
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/zigpy_deconz/zigbee/application.py", line 72, in connect
    self.version = await api.version()
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/zigpy_deconz/api.py", line 473, in version
    (self._proto_ver,) = await self[NetworkParameter.protocol_version]
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/zigpy_deconz/api.py", line 438, in read_parameter
    r = await self._command(Command.read_parameter, 1 + len(data), param, data)
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/zigpy_deconz/api.py", line 323, in _command
    return await asyncio.wait_for(fut, timeout=COMMAND_TIMEOUT)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

cc: @puddly

from deconz-serial-protocol.

I tried to use the old RasBee shield you sent to me 2 years back. Unfortunately I'm not able to make it running

Note that to use RaspBee (or any other Zigbee shield on a Raspberry Pi) you will need to first disable and/or enable some things depending on which exact Raspberry Pi model that you have; so either; disable Bluetooth + hciuart service and "uncomment to enable primary UART console" to enable UART via enable_uart=1 and dtoverlay=disable-bt in config.txt under boot directory to enable and free up the UART serial port on pins 14 and 15 of the GPIO header (applies to Raspberry Pi 3 and Raspberry Pi Zero W or newer), or enable shell mesages on the serial connection under interface options in raspi-config or alternativly disabling the Serial Login Shell (applies to the older Raspberry Pi 2, and the original Raspberry Pi + first-generation Raspberry Pi Zero). You should then be able to set device path to /dev/ttyACM0:

https://www.abelectronics.co.uk/kb/article/1035/serial-port-setup-in-raspberry-pi-os

https://www.google.com/search?q=raspbee+AND+%22dtoverlay%3Ddisable-bt%22+AND+%22enable_uart%3D1%22

If got older Raspberry Pi 2 or the original Raspberry Pi or Raspberry Pi Zero then configure user access rights of serial interface:

sudo raspi-config

1. Interfacing Options → Serial
2. Would you like a login shell accessible over serial? → No
3. Would you like the serial port hardware to be enabled? → Yes
4. Changes to access rights only become active after a restart.

If got the later Raspberry Pi 3 and Raspberry Pi Zero W or newer then instead edit the config.txt inside boot directly on storage:

sudoedit /boot/config.txt (noting edit via sudo nano /boot/config.txt or sudo vim /boot/config.txt will probably not work).

Then edit end of that file where it says to "uncomment to enable primary UART console" to also add dtoverlay=disable-bt:

enable_uart=1
dtoverlay=disable-bt

Some instructions say it should also work if re-enable BT via miniUART on newer Raspberry Pi with the latest firmware:

enable_uart=1
dtoverlay=disable-bt
dtoverlay=miniuart-bt

Anyway, then run commands to disable hciuart service

sudo systemctl disable hciuart
sudo systemctl stop [[email protected]](mailto:[email protected])
sudo systemctl disable [[email protected]](mailto:[email protected])

Changes to access only become active after a full reboot.

sudo reboot

from deconz-serial-protocol.

@Hedda, thanks my question is more to

1/ RasBee firmware versus RaspBee II ?
2/ My understanding is the connection works, so my setup is correct. Even teh command "sudo GCFFlasher_internal -l" workds

from deconz-serial-protocol.

Still no chance

rpi4 - bullseye

cat /boot/cmdline.txt
root=PARTUUID=6857d2a9-02 rootfstype=ext4 fsck.repair=yes rootwait

/boot/config.txt

enable_uart=1
dtoverlay=disable-bt

dmesg | grep tty

[    0.001837] printk: console [tty0] enabled
[    1.401231] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 38, base_baud = 0) is a PL011 rev2

ps -ef | grep tty

root       605     1  0 11:07 tty1     00:00:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
domoticz   821   653  0 11:10 pts/0    00:00:00 grep --color=auto tty

sudo GCFFlasher_internal -l

GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------
/dev/ttyACM0     | 0x1CF1 | 0x0030  | DE2227699  | ConBee II
/dev/ttyAMA0     | 0x0000 | 0x0000  |            | RaspBee

sudo GCFFlasher_internal -f deCONZ_Rpi_0x26400500.bin.GCF -d /dev/ttyAMA0 -x 3

GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
11:07:55:882 using firmware file: deCONZ_Rpi_0x26400500.bin.GCF
11:07:55:956 ls dev: /dev/ttyACM0 (0x1CF1/0x0030) sn: DE2227699
11:07:55:956 ls dev: /dev/ttyAMA0 (0x0000/0x0000) sn:
11:07:55:956 dev /dev/ttyAMA0
Reboot device /dev/ttyAMA0 (RaspBee)
11:07:55:957 query bootloader v1 ID after 0 ms
11:07:57:459 query bootloader v1 ID after 1501 ms
11:07:57:960 query deCONZ firmware version
11:07:59:963 uart reset failed, try RaspBee reset
action: reset device RaspBee
wiringPi 2.52 initialized
11:08:00:167 query bootloader v1 ID after 0 ms
11:08:00:656 RX 14 bytes ASCII ��� after 489 ms
11:08:00:656 RX c0818203000300357ee5d48bfcc0 after 489 ms
11:08:00:656 SLIP RX frame length: 10
11:08:00:656 check magic: 0x81 cmd: 0x82 after 490 ms
Bootloader version 0x00030003, app crc: 0xD4E57E35
11:08:00:657 GCF_ResetDeviceDone
11:08:00:659 bootloader v3 update firmware request size: 127650, addr: 0x00000000, type: 1, crc-32: 0xAAAAAAAA
11:08:00:659 TX c08103a2f201000000000001aaaaaaaa3efbc0

from deconz-serial-protocol.

If not using deCONZ did you try sudo GCFFlasher_internal -t 60 -f deCONZ_Rpi_0x26400500.bin.GCF as suggested in their wiki:

https://github-wiki-see.page/m/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually

or if updating from deCONZ Docker container then should use GW commands:

https://github.com/deconz-community/deconz-docker#updating-conbeeraspbee-firmware

Alternative methods to using GCFFlasher could be to install deCONZ app or Phoscon App Beta and update firmware from there? That is, I think that both the deCONZ app and Phoscon App Beta has built-in functions to update RaspBee and ConBee firmware.

Also, always make sure you got a very good power supply for RaspBerry Pi 4 and RaspBerry Pi 3 respectively as they are infamously known for not work properly with peripherals if do not correctly powered. As well as disable hciuart service if did not do so already.

Other than those I have no more tips myself, though hope you manage to flash the old RaspBee adapter and get it working :)

PS: To not go too much off-topic that first-gen RaspBee firmware upgrade problem now maybe belongs in some other forum(s)?

• Phoscon community forum -> https://phoscon.de/forum
• deCONZ Discord Chat -> https://discord.gg/APNK5TM
• GCFFlasher Github Issues -> https://github.com/dresden-elektronik/gcfflasher
• Phoscon App Beta Github Issues https://github.com/dresden-elektronik/phoscon-app-beta/issues

from deconz-serial-protocol.

As I understand the application firmware feature and function parity is the same for the first/old RaspBee and new RaspBee II?

Believe that the only relative practical difference is that the RaspBee II hardware has a newer radio chip MCU model == better?

That was maybe a wrong assumption? See -> https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Firmware-Changelog

"Note: The number differences between I and II series don't represent feature or bugfix equality as there are different underlying Zigbee stacks in use."

As I understand the older first-generation ConBee and RaspBee products are based on some older NXP 8-bit AVR based MCU chip with NXP Zigbee stack(?) and then they added their own proprietary "deCONZ" application firmware (application layer) with custom APIs(?). While the newer ConBee II and RaspBee II are base on a Microchip ATSAMR21E18A 32-bit Arm Cortex-M0 MCU, so presumable that instead uses Microchip Stack for the Zigbee Protocol and then Dresden Elektronik ported their own proprietary "deCONZ" application firmware with custom APIs to that too(?). It is also possible to run DRS ZBOSS Zigbee Stack on both older NXP chips as well as the newer Microchip ATSAMR21G18A chips.

Regardless it would explain the APIs being the same but there not being feature or bugfix parity between the older older first-generation firmware for first-generation ConBee and RaspBee hardware and the the newer ConBee II and RaspBee II.

PS: I believe this is a similar practice to ZiGate with the exception that their application firmware (application layer) is open source.

from deconz-serial-protocol.

Thanks for the mail the samples should arrive quickly :)

• Not possible to form a new network and to change the Extended PAN Id ( a must for Legacy Wiser devices)
• Not possible to add coordinator Endpoint as for ZNP or Ezsp (for exemple) this prevent having
  Wiser legacy and Wiser paired and working Livolo switch

The serial protocol allows to specify Extended PANID ("APS Use Extended PANID" parameter) and to configure custom endpoints/clusters. These need be set while the network is disconnected and become active after network start.

@manup could you kindly clarify which API needs to be use to configure custom endpoints/clusters that ?

from deconz-serial-protocol.

@manup when you say 3 endpoints are supported: 0-2, is that in addition of the standard ZCL 0x01 EndPoint, or does it includes 0x01, and so we can add only 2 End Points ?

from deconz-serial-protocol.

@puddly is that enough to make a similar API as you did for znp ?

            await self._znp.request(
                c.AF.Register.Req(
                    Endpoint=endpoint,
                    ProfileId=zigpy.profiles.zha.PROFILE_ID,
                    DeviceId=zigpy.profiles.zll.DeviceType.CONTROLLER,
                    DeviceVersion=0b0000,
                    LatencyReq=c.af.LatencyReq.NoLatencyReqs,
                    InputClusters=[clusters.general.Basic.cluster_id],
                    OutputClusters=[],
                ),
                RspStatus=t.Status.SUCCESS,
            )

from deconz-serial-protocol.

Is this necessary? Only ZNP requires explicit endpoint registration as far as I can tell: zigbeefordomoticz/Domoticz-Zigbee#1090 (comment)

from deconz-serial-protocol.

Is this necessary? Only ZNP requires explicit endpoint registration as far as I can tell: zigbeefordomoticz/Domoticz-Zigbee#1090 (comment)

Seems that my test was not relevant. I made the same test on ZNP without ep registration and this device paired without problem.
Could you clarify when ep registration is needed? I'm quite lost. Is it only if the device send command on specific endpoint ?

from deconz-serial-protocol.

Is this necessary? Only ZNP requires explicit endpoint registration as far as I can tell: zigbeefordomoticz/Domoticz-Zigbee#1090 (comment)

@puddly yes it is necessary for pairing the Livolo switch, getting the Wiser Thermostat (touch) working.
The issue is when you have a Device sending a ZCL command like a Read Attribute Request to an Ep != 0x01 the message is not transmitted to the UART.

This was the case with ZNP and we have added those Ep and it works like a charm
This was the case with Zigate this was added at the firmware level and make it working

from deconz-serial-protocol.

The next gen is based on Silabs and will also use the same serial protocol.

@manup is that "next-gen" as in the new Silicon Labs EFR32MG24 chip will be used in upcoming "ConBee III" and "RaspBee III"?

from deconz-serial-protocol.

The EFR32MG24 is under consideration but not available yet, more likely we go for for EFR32MG21 which we already use in other products to consolidate chip diversity. As a side node, contrary to common believe there isn't a real difference from a users perspective in comparison for the R21 in ConBee II / RaspBee II. All these chips are insanely fast in terms of Zigbee performance and the workload and memory intensive stuff is handled in the host application. :)

The real fixed bottlenecks are the same for all chips, that is the 250 kbps of the radio which only can transmit one message in serialized manner, and the legal restrictions for max. transmit power of ~10 dBm.

Quite interesting here is the OpenThread stack which we'll support also for ConBee II / RaspBee II as Border Router. It has configurable architecture and allows the radio firmware to be simple and out source the heavy parts to the host application.

from deconz-serial-protocol.

@manup Thanks for the details. Is it worth considering increasing the endpoint registration number limit ?
We are not yet using green power, which let us 2 endpoint registrations free.
For your information, here the list used by the plugin:
0x0b: Schneider Wiser
0x03: New Schneider Wiser
0x0a: Orvibo
0x6e: Terncy
0x15: Konke
0x08: Livolo

On each above endpoint, requests are made from the device on another endpoint than 0x01. I've made some further test and for example, the wiser thermostat have requests (Read Attributes and Report Attributes) from 0x0b to 0x0b.
With the current limit, we'll have to implement a list of options for the user.

Other coordinators are not impacted by this kind of limit, the more surprising is EZSP with silabs chips, all the endpoints are driven to the application level without registration.

from deconz-serial-protocol.

I'd highly recommend to just use one endpoint, perhaps two, for outgoing messages. Having one for each vendor scales not so well considering the growing number devices and vendors. Note you can send from one source endpoint (for example 0x01) to any destination endpoint, they don't need to be the same.

On the incoming side it we have seen only one device in the wild which did expect a specific endpoint number on the coordinator, for that there was fix in the firmware to forward the command to the application.

from deconz-serial-protocol.

from deconz-serial-protocol.

Ah ok understand, you may check if the outgoing command from coordinator uses an existing source endpoint from the coordinator, the device the coordinator talks to should always pickup the right source endpoint from the message and use it as destination endpoint for replies.

For commands which are send from a device to the coordinator without prior request the devices query endpoints and clusters first via ZDP Match_Descr_req (e.g. OTA, Time).

For ZCL reporting the bindings need to be configured with a destination endpoint existing on the coordinator.

from deconz-serial-protocol.

@manup

We have reverse-engineered the all Wiser Legacy and despite how the Coordinator is configured there are some hard coded Request Attribute Request from Wiser End Device which send to a dedicated Ep on the coordinator.

I'm talking about a ZCL command Read Attribute Request ( not a report, not a response)

from deconz-serial-protocol.

Interesting might be a good issue to forward to Wiser, do you have a modelid?

from deconz-serial-protocol.

We are not yet using green power, which let us 2 endpoint registrations free.

FYI, zigpy does not yet support ZGP (Zigbee Green Power) so for zigpy ZGP discussion see zigpy/zigpy#656 and zigpy/zigpy#341

from deconz-serial-protocol.

Interesting might be a good issue to forward to Wiser, do you have a modelid?

Manu this is Legacy Wiser from Schneider. Not supported anymore , so I don't think this make sense to forward the issue to them.

Basically , we have (on the plugin side) do a full reverse engineering of the Wiser legacy equipement ( Thermostat, Valve, Actuator, and also Wiser sMeter .

https://www.se.com/fr/fr/product/EER51000/wiser-thermostat/
https://download.schneider-electric.com/files?p_Doc_Ref=Wiser-Smartplug_EAV89774-01_EER400xx_10-2016_DA-EN-FR-IT-SV
https://www.materielelectrique.com/content/cms/wiser_24062015/medias/noticeconcentrateur.pdf

So for me the ALL eco-system works really great on Zigate , ZNP, ENZP and unfortunately not on deConz .
Now if we can extend zigpy-deconz to allow custom Ep (at least 1 ) this will make it running.

This is similar for the Livolo switch which send a Read Attribute Request to "report" its current state.

from deconz-serial-protocol.

@manup Thank you for the parameter definition! I have a question regarding endpoint "index" 0x02: I receive an UNSUPPORTED status code for both reads and writes. Does the Conbee II not support all three endpoints? I get the same behavior when specifying any index greater than 0x01, while 0x00 and 0x01 all work as expected for both reads and writes.

from deconz-serial-protocol.

@manup have you been able to progress on the firmware able to manage more than 2 Eps ?

from deconz-serial-protocol.

@pipiche38 Can I suggest that you also post many new separate issues to https://github.com/dresden-elektronik/deconz-serial-protocol/issues for each specific issue so that to help @manup and others track different issues here in their upstream repository?

from deconz-serial-protocol.

@manup have you been able to progress on the firmware able to manage more than 2 Eps ?

from deconz-serial-protocol.