8000 RFC: Zigpy/API/Radio schemas · Issue #381 · zigpy/zigpy · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
/ zigpy Public
  • Notifications You must be signed in to change notification settings
  • < 8000 a icon="repo-forked" id="fork-button" href="/login?return_to=%2Fzigpy%2Fzigpy" rel="nofollow" data-hydro-click="{"event_type":"authentication.click","payload":{"location_in_page":"repo details fork button","repository_id":120253126,"auth_type":"LOG_IN","originating_url":"https://github.com/zigpy/zigpy/issues/381","user_id":null}}" data-hydro-click-hmac="b642b2e54339542d8eff40a0244ddc0e65c8d4d4f347f05904eea446cb78fcc5" data-view-component="true" class="btn-sm btn"> Fork 183
  • Star 932

RFC: Zigpy/API/Radio schemas #381

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Adminiuga opened this issue Apr 16, 2020 · 39 comments
Closed

RFC: Zigpy/API/Radio schemas #381

Adminiuga opened this issue Apr 16, 2020 · 39 comments

Comments

@Adminiuga
Copy link
Collaborator

ZHA integration relies on python modules providing interface to Zigbee radios/network and all those modules are using zigpy library for basic ZCL/ZDO interfaces and a basic ControllerApplication.

With diversification of supported modules/protocols, it become problematic to have an uniform interface between ZHA and respective radio module/library, because technically ZHA is not integrating with Zigpy, but with the radio module itself. In other words zigpy has just a subset of configuration options a given radio module could implement.

With that in mind in 0.20.0 we introduced schemas/configuration dict as a mean to pass parameters from ZHA integration to radio lib implementing interface with the radio.

Most (All?) Zigpy based libraries are currently following this layout:
zigbee.application.ControllerApplication() <->API() <--> Uart()

The idea was to have a "configuration" dict which we could pass to ControllerApplication() instance and let it parse, handle and pass the required bits to the underlying layers like API() and Uart/Gateway() instances.

My idea was to allow Zigpy to define schema which affects configuration options independent of the radio being used (e.g. OTA) or options which can be implemented by all the radios (e.g. permit()) using zigpy.
Radios are allowed to extend this schema and include radio specific options.

ATM, current Zigpy schema could be represented by the following .yaml

database_path: /config/zigbee.db

ota:
    ikea_provider: False
    ledvance_provider: False
    otau_directory: /config/zigpy_ota

device:
    path: /dev/ttyUSB0

And for example bellows extends the above schema with the following options:

device:
    baudrate: 57600

source_routing: False

ezsp_config:
    CONFIG_APS_UNICAST_MESSAGE_COUNT: 10
    CONFIG_ROUTE_TABLE_SIZE: 16
....

Making it all work with ZHA integration config entry options is going to be an interesting challenge (for @dmulcahey :) but that's another story.
I'm open for feedback/suggestions whether it meets the current needs and/or what could be improved?

@puddly @doudz @sanyatuning @billyburly
@Adminiuga
Copy link
Collaborator Author

pasting from another repo:

Is there a reason for why the device schema is passed to both the API and the UART? There are a few configuration options that the API accesses that would essentially have to be passed from the Application to the API to get around the schema structure, which I'm "fixing" by just extending the device schema: https://github.com/zha-ng/zigpy-znp/blob/a6be2f8b2a801ee61df7871f467828d419bb9424/zigpy_znp/config.py#L25-L41

Also, will this schema be replacing the form_network method's arguments as well?

@Adminiuga Adminiuga mentioned this issue Apr 16, 2020
Closed
@puddly
Copy link
Collaborator
puddly commented Apr 16, 2020

What do you think about this structure?

# Core zigpy config
database_path: /config/zigbee.db

# Optional zigpy config
ota:
    ikea_provider: False
    ledvance_provider: False
    otau_directory: /config/zigpy_ota

# Core device config, used by all radios
device:
    path: /dev/ttyUSB0
    baudrate: 57600

    # Optional network config, used by all radios
    network:
        channels: [15, 16, 20]
        network_key: '64249a501265ba33494071bf2a72e3f1'
        pan_id: 0x1234
        extended_pan_id: 0x12345678

    # Optional radio-specific config
    ezsp_config:
        CONFIG_APS_UNICAST_MESSAGE_COUNT: 10
        CONFIG_ROUTE_TABLE_SIZE: 16

The top-level device config can then be passed to the controller application, probe, new, etc., since unused keys would be ignored.

Also, the new changes bring new API classmethods, like new and probe. Does the API (or equivalent) class have any expected structure or can it be treated as internal? If so, I think the probe method (and new?) should be moved to the controller application as well, as that can be exported by any compatible radio library as module_name.ZIGPY_CONTROLLER_APPLICATION (or similar), removing the need for any unnecessary hard-coding upstream.

@Adminiuga
Copy link
Collaborator Author
Adminiuga commented Apr 16, 2020 •
edited
Loading

this is the feedback i'm looking for. To answer the 1st part, I was going by bellows structure and historically bellows configures everything from the ControllerApplication() and there was no need to pass anything extra to EZSP() (or API() in other libs) other than the device information.
And I didn't have the urge to pass anything extra for XBee or ConBee based modules.

But now, since you are asking, I can see how this could be useful. So how about this approach:

  1. DEVICE_SCHEMA should keep only options required for the serial port: e.g. path, baudrate, flow_control and maybe for Zigate something like set_pizigate_running_mode so that doesn't have to be encoded in the port path.
  2. ControllerApplication() should pass the entire configuration dict to the lower API layer and let API to pick the keys it need and pass the device key section down to the port.
    My preference for the radio lib to keep API layer options in its own unique key/section, e.g.
znp_config:
    auto_reconnect: True  # would you really want this off???
    tx_power: 0
    sreq_timeout: 5
etc

Thus there won't be collisions between different radio libs and I'm hoping that should make things easier for ZHA

Also, will this schema be replacing the form_network method's arguments as well

I was thinking about it, but left it for a later PR, however no reason to not get the feed back.
Was thinking about network section (better name alternatives???) and the following params

network:
    update_id: 1
    pan_id: 0x1234
    extended_pan_id: 00:11:22:33:44:55:66:77:88
    trust_center: 11:22:33:44:55:66:77:88:99
    mac_address: 22:33:44:55:66:77:88:99:00  # probably not all radios can change MAC?
    network_key: [1, 2, 3, 4, ... 16]
    channel_mask: 0x12345678
    channel: None
  1. Anything else we should have here?
  2. should channel_mask and channel options be mutually exclusive?
  3. what options are "nice to have" and which ones are "must to have"?

@puddly
Copy link
Collaborator
puddly commented Apr 16, 2020

1., 2. I think relaxing the structure of the radio modules and just expecting a ControllerApplication subclass with a probe classmethod would be the easiest way to deal with the varying requirements for the different radio modules (for me, at least). That way, the controller application can deal with the config dict however is simplest for the radio module. For example, I only created the auto_reconnect option so that I could disable it in the API.probe method, which is passed only the device portion of the config. If the API-like class (and the UART) are made private for each radio module, I don't think any functionality will be lost.

 2. I haven't looked deeply into other radio modules' handling of channels, but I know that TI's ZNP has a primary and secondary (backup) channel mask that it scans on startup to choose the network's channel. There's no way to actually specify an individual channel other than creating a channel mask with that single channel. Is there a benefit to picking a specific channel while selecting more channels in the channel mask?

@Adminiuga
Copy link
Collaborator Author

Also, the new changes bring new API classmethods, like new and probe. Does the API (or equivalent) class have any expected structure or can it be treated as internal?

API (or equivalent) is totally up to the radio lib implementation, as it is going to be used only by the ControllerApplication() from the respective lib.

If so, I think the probe method (and new?) should be moved to the controller application as well, as that can be exported by any compatible radio library as module_name.ZIGPY_CONTROLLER_APPLICATION (or similar), removing the need for any unnecessary hard-coding upstream.

I was torn about it. Since for the probe() method I was only requiring the device section and we already had all APIs in the ZHA integration i left it in API.

But I was thinking about exposing is either as a static class method of the module_name.zigbee.application.ControllerApplication() or as a function in module_name.zigbee.application module

@Adminiuga
Copy link
Collaborator Author

I only created the auto_reconnect option so that I could disable it in the API.probe method, which is passed only the device portion of the config. If the API-like class (and the UART) are made private for each radio module, I don't think any functionality will be lost.

I'm not quite following. My intention for for the probe method, regardless of where it is going to be implemented is the following: Take device section of the config, in other words a dict of port path and anything else defining connection to the serial port and return True if you could open port and detect radio on it (got a response to a command) or False other wise. The idea is to use it in config entry validation routine, to validate user has input correct port and radio type.

@Adminiuga
Copy link
Collaborator Author
  1. I haven't looked deeply into other radio modules' handling of channels, but I know that TI's ZNP has a primary and secondary (backup) channel mask that it scans on startup to choose the network's channel. There's no way to actually specify an individual channel other than creating a channel mask with that single channel. Is there a benefit to picking a specific channel while selecting more channels in the channel mask?

I think the primary channel mask is applicable to all radios. Just not sure whether the coordinator scans the channel and might change channel on every start up or only during network formation. I was under impression that to change the channel you need to send a network update to all devices on the current channel then actually change the channel. But devices get and save channel mask upon joining the network and scan for their pan_id accordingly channel mask on every startup

@Hedda
Copy link
Contributor
Hedda commented Apr 17, 2020 •
edited
Loading

@doudz you might also want to be in on this discussion about zigpy API and radio schemas as believe that different zigpy-zigate radios could also be in need of custom configuration options too, or?

@Hedda Hedda mentioned this issue Apr 17, 2020
Closed
@Hedda
Copy link
Contributor
Hedda commented Apr 17, 2020 •
edited
Loading

As I understand it #372 is also related to this as a "TX Power" setting is an example of an optional extension that is maybe not used by all radio libraries will use but zigpy / ZHA need to be able to permit and configure its option setting.

@Hedda
Copy link
Contributor
Hedda commented Apr 17, 2020

Perhaps it should just be noted that I have read that a few projects out there still use bellows as a stand-alone library without zigpy, and the same might hold true for other radio libraries for zigpy too.

@Hedda
Copy link
Contributor
Hedda commented Apr 17, 2020 •
edited
Loading

Regarding serial port path, perhaps also consider also including IP-network configuration there too?
...keeping in mind that such as IP network configuration might be confused with Zigbee network?

(Please excuse ranting below but I been very existed recently reading about the new Sonoff ZBBridge).

Anyway, ZiGate WiFi module needs config for IP-address and TCP-port (also user and password?)?

https://zigate.fr/produit/zigate-pack-wifi-v1-3/

To configure Wi-Fi ZiGate you need to specify IP-address & TCP-port, ex : socket://192.168.1.10:9999

I have also submitted a remote network-connection (Ethernet/Wi-Fi) related request in #297 because I personally run Home Assistant with ZHA in a virtual machine on a Synology NAS and know that many others also run Home Assistant with ZHA on a server that is physically located poorly in the house for Zigbee reception so I would very much like for it to be simple to connect Zigbee adapter/module remotely via example a networked Raspberry Pi or ESP8266/ESP32 (i.e. a networked Arduino) located somewhere else in the house.

As I understand people wanting to add network-connected adapter remotely today just use ser2net

https://www.zigbee2mqtt.io/how_tos/how_to_connect_to_a_remote_adapter.html

As requested in #297 it would be very nice to in the future see other network-connected adapters remotely on Raspberry Pi via some kind of easy to use bridge/gateway software based on a client-server model idea where it maybe just encapsulate (and preferably for security also encrypt) the serial communication for secure communication over a local LAN network, forcing one to on the client-side (i.e. zigpy / ZHA) enter username and password that has been set on server-side (i.e. the software running on a Raspberry Pi with the Zigbee adapter), or at least some kind of unique-code randomly generated on initialization by the server-side.

It would, for example, be cool to see the Zigee2Tasmota subproject for 8000 the Tasmota ESP8266 firmware extended to do something similar for a TI CC2530 module as the ZiGate WiFi module does:

Itead has also just announced a similar Sonoff Zigbee Bridge / Gateway based on an EZSP module:

So how awesome wouldn't be to run Zigee2Tasmota on Sonoff ZBBridge controlled from zigpy / ZHA?

@Adminiuga
Copy link
Collaborator Author

Regarding serial port path, perhaps also consider also including IP-network configuration there too

There's no need. path is being passed serial_asyncio as a str and zigpy-zigate is already supporting this.

@puddly
Copy link
Collaborator
puddly commented Apr 17, 2020

Thanks for the clarification. I've made probe a classmethod of ControllerApplication and moved the radio-specific config under its own key.

Regarding the network schema:

  • what is the purpose of the update_id? Is it something the user increments every time they make a change?

  • what about using channels: [15, 16, 21] and preferred_channel: 16? All of the radio modules supporting the former option can use t.Channels.from_channel_list to make a mask, which keeps the config human-readable. The latter option isn't supported by all radios and making it seem more like a suggestion makes its purpose clear.

@Adminiuga
Copy link
Collaborator Author

Thanks for the clarification. I've made probe a classmethod of ControllerApplication and moved the radio-specific config under its own key.

Excellent. I think this way ZHA doesn't need to know anything about the "API" or equivalent module and you are free to use whatever interface to pass configuration between controller application and api module.
The only thing now, I'd need to know the device schema, so I'm proposing to add a SCHEMA_DEVICE attribute containing "device vol schema" for the particular module, so I could use it in config entry.

what is the purpose of the update_id? Is it something the user increments every time they make a change?

Essentially yes. I interpret it as a version id of a configuration. AFAIK it should be incremented if you change channel, network key etc and then broadcast to all devices. In docs references as NwkUpdateId . For example this is what Emberznet is using to form the network
image

what about using channels: [15, 16, 21] and preferred_channel: 16? All of the radio modules supporting the former option can use t.Channels.from_channel_list to make a mask, which keeps the config human-readable. The latter option isn't supported by all radios and making it seem more like a suggestion makes its purpose clear.

Works for me. I'm expecting most radios to support the mask and fewer to support preferred channel, but in this case that particular radio implementation can drop the preffered channel and use the mask only.

Real question though: what should be the default channel mask? should we include all channels or just [11, 15, 20] because of the Konke devices which join only on those channels?

@puddly
Copy link
Collaborator
puddly commented Apr 17, 2020 •
edited
Loading

Briefly looking at the individual libraries:

  • bellows passes 0 as the channel mask to EZSP, which seems to be every ZigBee channel, though it specifically uses channel 15.
  • zigpy-xbee seems to behave similarly. There's some CH AT-command to specify the mask but I don't know what the default mask is.
  • zigpy-deconz seems to leave everything as the default.
  • zigpy-cc and zigpy-znp both use just channel 15.

15 seems to be the current (non-configurable) default and users didn't seem to mind so using [15, 20, 25] probably won't hurt. Those three Zigbee channels also are the least-affected by the three non-overlapping 2.4GHz WiFi channels (1, 6, and 11) that most routers should be using (at least in North America) and would make a good default mask.

https://github.com/dresden-elektronik/deconz-rest-plugin/issues/825#issuecomment-427139292

@Adminiuga
Copy link
Collaborator Author

[15, 20, 25] for the channels it is then.

This was referenced Apr 20, 2020
Closed
Closed
@Hedda
Copy link
Contributor
Hedda commented Apr 20, 2020 •
edited
Loading

Also related to zigpy/zigpy-znp#20 and #384 and zigpy/zigpy-cc#42 as another optional extension?

zigpy-znp request # 20 = Allow option to disable and enable LED/LEDs on adapter or board
zigpy-cc request # 42 = Option to disable LED on cc2531
zigpy request # 384 = Allow option to disable and enable LED/LEDs on adapter

Option to configure settings for disabling and enabling LED/LEDs on the Zigbee radio adapter/dongle.

@Hedda Hedda mentioned this issue May 13, 2020
Closed
@Hedda
Copy link
Contributor
Hedda commented May 13, 2020 •
edited
Loading

Any more thought on allowing configuration of TX Power strength for modules with Power Amplifier?

As per requests zigpy/zigpy-znp#11 for zigpy-znp and zigpy/zigpy-cc#33 for zigpy-cc radio libraries.

@Hedda Hedda mentioned this issue May 13, 2020
Open
@Adminiuga
Copy link
Collaborator Author

Atm can be done by radio lib extending the base schema.

@Hedda
Copy link
Contributor
Hedda commented May 15, 2020

Tip on a channel guide -> https://www.metageek.com/training/resources/zigbee-wifi-coexistence.html

@pipiche38 pipiche38 mentioned this issue Sep 3, 2020
Closed
@pipiche38
Copy link
Contributor

[15, 20, 25] for the channels it is then.

Just a comment from my little experience. Most of the devices works on Channel 11.
Some Controller accept 0 as a channel input and then select automatically the best channel at Network initialization.

@Adminiuga
Copy link
Collaborator Author

Yes, channel 11 is a standard channel so most devices should support worki g on that channel. These were select because they fall between wifi channels and get less interference

@puddly
Copy link
Collaborator
puddly commented Sep 4, 2020

Is there a reason for why we're hardcoding channel 15 as the default? Right now there's no trivial way to force TI radios to use a specific channel and instead the radio finds the best of 15, 20, 25 to form the network on, which seems like good default behavior for other radios as well.

@pipiche38
Copy link
Contributor

Cannot you add channel 11 in that list. In such I think that would be a better default as this will embarked Channel 11

@puddly
Copy link
Collaborator
puddly commented Sep 4, 2020

Zigbee channel 11 overlaps with WiFi channel 1 and Konke devices will not try joining networks that are not on channels 15, 20, 25, which doesn't make it a very good default.

@pipiche38
Copy link
Contributor
pipiche38 commented Sep 4, 2020 •
edited
Loading

Ok, but then Legrand works only on 11, so you won't get Legrand devices if you do not specify the channel. So from my end not putting 11 is too restrictive. As you don't have 26, Livolo will not join the network either!

My advice today on Zigbee, is to use channel 11 by default, and make sure Wifi is not channel 1

As the Konke devices, you have to make it joining 15 , and then you have to switch your network to 11, and the Konke devices will follow by themselves.

@puddly
Copy link
Collaborator
puddly commented Sep 4, 2020

Hmm, I didn't know about those other devices.

  • I can choose my WiFi network's channel but I can't ask all of my neighbors to do this as well. Of the 19 networks I can pick up right now, 18 are on channels 1, 6, 11. WiFi networks can easily change channels and most networks nowadays will be formed on those three. Zigbee cannot as easily, so if you form a network on a quiet channel today, there's no guarantee that it won't become congested in the near future when your neighbors' routers auto channel feature moves their WiFi networks right on top of your Zigbee network.

  • For some radios (CC2530 + CC2591, possibly EZSP?), Channel 26 has reduced TX power in North America due FCC restrictions.

Sill, these are just defaults, you can change them when forming your network. It'd be useful to include the current channel and channel mask in the HA user interface somehow, they're already standard properties on ControllerApplication.

@dmulcahey
Copy link
Collaborator

It'd be useful to include the current channel and channel mask in the HA user interface somehow, they're already standard properties on ControllerApplication.

I agree. It’s on the radar. That said, it will probably have to go in advanced mode as I don’t think they’ll approve it if it is always front and center. I think we should also do an energy scan and default to the best channel in the 15, 20, 25 group for “normal” mode... thoughts?

@puddly
Copy link
Collaborator
puddly commented Sep 4, 2020

It appears that TI radios do only an active scan (looking just for other Zigbee networks) when forming a network to pick the "best" channel and a non-conflicting PAN ID:

To create a network, the coordinator node scans the RF environment for existing networks, chooses a channel and a network identifier (also called PAN ID) and then starts the network.

Perhaps letting the radio pick the network settings and then exposing some ZCL-based, adapter-agnostic network scanner for performing energy/active scans would let users pick a better channel if they feel like it (maybe once the channel migration feature is being worked on)?

All of this UI stuff is easy to write about but actually implementing it seems like a daunting endeavor.

@dmulcahey
Copy link
Collaborator
dmulcahey commented Sep 4, 2020 •
edited
Loading

Why couldn’t we do the scan on our own before we save the config?

Edit: in normal mode, no channel picked by user and config is saved -> energy scan, pick best channel present in the channel mask, persist that in the config, form the network?

@pipiche38
Copy link
Contributor
pipiche38 commented Sep 4, 2020 •
edited
Loading

Here is how ZiGate based on the Zigbee 3.0 stack behave.

If you ask to form a new network and you give a network mask of 0x00000000, then it will do an energy scan, select the best channel and form the new network with that channel. The main concerns I have with that approach is you don't control it. and as stated earlier @puddly some devices requires specific channel (Konke 15, 20 and 2; Livolo 26; Legrand 11; Schneider 11 and 15). So having a channel mask to a reduced number of channel will always make someone unhappy.

[edit] by experience , if you are in a dense zone, the controller and the energy scan is not going to help you as the Wifi is going to overlap most of the zigbee channels. So except if you are in a wild field, I'm afraid that the scan will not really help you (at least that what I have seen in a number of ZiGate users).

@puddly
Copy link
Collaborator
puddly commented Sep 4, 2020

I guess you could somehow balance the results of the energy scan (low non-Zigbee background noise) with the results of an active scan (few Zigbee networks on the same channel) to pick a good initial channel.

When I get some more free time I will try to test out how channel migration works with Xiaomi devices. Maybe it's simple.

@pipiche38
Copy link
Contributor

I have discussed the matter of interferences with a Zigbee device manufacturer (blinds) and their analysis is as the Zigbee is a low-powered device it is affected by almost everything on the Radio .
Of course the Wifi 2.4 Ghz, but he mentioned also the 5 Ghz could affect the Zigbee one (whatever the zigbee channel) if too closed to Zigbee devices/controller. Even more IP Web cam when streaming can make a lot of disturbance.

With Xiaomi devices, just forget. No channel migration. I have seen it working for Konke from 15 to 11, for Livolo from 26 to 11, Heiman seems to be the best.

Xiaomi has a lot of defect. They for instance have a firmware bug where if the device receive a Leave and Rejoin command, will leave but never try to rejoin . That is the most annoying bug that we have.

@Adminiuga
Copy link
Collaborator Author

When I get some more free time I will try to test out how channel migration works with Xiaomi devices. Maybe it's simple.
Share the results. In my experience xiaomi did not like pan-id change, which is same channel, just different pan-id.

as about the automatic channel selection, probably better just ask user on what channel to form the network or leave it up to the radio lib implementation. We can have a convention if the channel == 0x00 then do an energy scan and pick a channel.

Realistically speaking, until now the default channel 15 worked pretty good for everyone. And unless you are dev, it is unlikely you are going to have more than one network on channel 15, but even with two-three zigbee networks on channel 15, including the production one I did not have too many issues.

IMO, maybe it is better to have ability to change the channel after the network was formed?

@Adminiuga
Copy link
Collaborator Author

I have discussed the matter of interferences with a Zigbee device manufacturer (blinds) and their analysis is as the Zigbee is a low-powered device it is affected by almost everything on the Radio .
Of course the Wifi 2.4 Ghz, but he mentioned also the 5 Ghz could affect the Zigbee one (whatever the zigbee channel) if too closed to Zigbee devices/controller. Even more IP Web cam when streaming can make a lot of disturbance.

It's all true, but why Legrand chose channel 11 as the default and only channel is beyond me. I would understand channel 25 or 26, but 11 🤯

@pipiche38
Copy link
Contributor

I have discussed the matter of interferences with a Zigbee device manufacturer (blinds) and their analysis is as the Zigbee is a low-powered device it is affected by almost everything on the Radio .
Of course the Wifi 2.4 Ghz, but he mentioned also the 5 Ghz could affect the Zigbee one (whatever the zigbee channel) if too closed to Zigbee devices/controller. Even more IP Web cam when streaming can make a lot of disturbance.

It's all true, but why Legrand chose channel 11 as the default and only channel is beyond me. I would understand channel 25 or 26, but 11 🤯

No clue why they did it. I'll see if I can get an answer on that.

@pipiche38
Copy link
Contributor

as about the automatic channel selection, probably better just ask user on what channel to form the network or leave it up to the radio lib implementation. We can have a convention if the channel == 0x00 then do an energy scan and pick a channel.

IMO, maybe it is better to have ability to change the channel after the network was formed?

I'm pretty supporting the approach, and the possibility to move from one channel to an other after network formed is a must.
On ZiGate this would required a soft-reset of the NXP stack as far as I understood and that is what we are doing.

@Hedda
Copy link
Contributor
Hedda commented Sep 7, 2020 •
edited
Loading

FYI, zigbee2mqtt / zigbee-herdsman developers has only managed to get the Hue Tap Switch Model 9290011152X by Philip (which is a ZGP = Zigbee Green Power device) to work on channel 11, 15, 20 or 25. More info in zigpy/zha-device-handlers#477

but why Legrand chose channel 11 as the default and only channel is beyond me. I would understand channel 25 or 26, but 11

No clue why they did it. I'll see if I can get an answer on that.

@pipiche38 Are you sure that all your Legrand and Netatmo devices will only pair on channel 11 or could it be that it supports one or more other specific channels as well? Wonder if the manufacturer has this information about supported channels in the device user-manual?

No mention about specific pairing channel for Legrand devices in zigbee2mqtt which they do mention on a few other devices https://www.zigbee2mqtt.io/information/supported_devices.html I read there on zigbee2mqtt supported devices that some other devices are also picky about which channels are supported for initial pairing but you would think that it should say in the manual from the manufacturer.

@pipiche38
Copy link
Contributor
pipiche38 commented Sep 7, 2020 via email

@Hedda Hedda mentioned this issue Sep 9, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dmulcahey @Adminiuga @Hedda @pipiche38 @puddly
0