Zigbee2mqtt: Removed devices (routers) are join to the network again.

[antti365]

@Koenkk I remove the bulb from the network and it immediately joins again, although the addition of new devices is prohibited. Similarly, the outlet behaves.

2/17/2019, 12:42:20 AM - debug: Received MQTT message on 'zigbee2mqtt/bridge/config/permit_join' with data 'false'
2/17/2019, 12:42:20 AM - info: Zigbee: disabling joining new devices.
2/17/2019, 12:42:20 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"log_level":"debug","permit_join":false}'
2/17/2019, 12:42:41 AM - debug: Received MQTT message on 'zigbee2mqtt/bridge/config/remove' with data 'Ikea_Bulb'
2/17/2019, 12:42:41 AM - debug: Received zigbee message of type 'devLeaving' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:41 AM - warn: Message without device!
2/17/2019, 12:42:41 AM - info: Successfully removed 0x000b57fffe8d1c04
2/17/2019, 12:42:41 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"device_removed","message":"Ikea_Bulb"}'
2/17/2019, 12:42:44 AM - debug: Received zigbee message of type 'devInterview' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:44 AM - info: Connecting with device...
2/17/2019, 12:42:44 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
2/17/2019, 12:42:44 AM - debug: Received zigbee message of type 'devInterview' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:44 AM - info: Connecting with device...
2/17/2019, 12:42:44 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
2/17/2019, 12:42:44 AM - debug: Received zigbee message of type 'devInterview' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:44 AM - info: Connecting with device...
2/17/2019, 12:42:44 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
2/17/2019, 12:42:45 AM - debug: Received zigbee message of type 'devInterview' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:45 AM - info: Connecting with device...
2/17/2019, 12:42:45 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
2/17/2019, 12:42:45 AM - debug: Received zigbee message of type 'devInterview' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:45 AM - info: Connecting with device...
2/17/2019, 12:42:45 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
2/17/2019, 12:42:46 AM - debug: Received zigbee message of type 'devInterview' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:46 AM - info: Connecting with device...
2/17/2019, 12:42:46 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
2/17/2019, 12:42:46 AM - debug: Received zigbee message of type 'devInterview' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:46 AM - info: Connecting with device...
2/17/2019, 12:42:46 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
2/17/2019, 12:42:46 AM - debug: Received zigbee message of type 'devInterview' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:46 AM - info: Connecting with device...
2/17/2019, 12:42:46 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
2/17/2019, 12:42:47 AM - debug: Received zigbee message of type 'devInterview' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:47 AM - info: Connecting with device...
2/17/2019, 12:42:47 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
2/17/2019, 12:42:47 AM - debug: Received zigbee message of type 'devInterview' with data '"0x000b57fffe8d1c04"'
2/17/2019, 12:42:47 AM - info: Connecting with device...
2/17/2019, 12:42:47 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
2/17/2019, 12:42:47 AM - debug: Received zigbee message of type 'devIncoming' with data '"0x000b57fffe8d1c04"' of device 'TRADFRI bulb E14 W op/ch 400lm' (0x000b57fffe8d1c04)
2/17/2019, 12:42:47 AM - info: Device incoming...
2/17/2019, 12:42:47 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"device incoming"}'
2/17/2019, 12:42:47 AM - info: New device with address 0x000b57fffe8d1c04 connected!
2/17/2019, 12:42:47 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"device_connected","message":"0x000b57fffe8d1c04"}'
2/17/2019, 12:42:47 AM - debug: Received zigbee message of type 'devStatus' with data '"online"' of device 'TRADFRI bulb E14 W op/ch 400lm' (0x000b57fffe8d1c04)

UPD:
It turns out that not only routers do this, after 20 min a switch has joined them. Networking is still disabled. What is going on with me? :)
And I didn't even press the pairing button on the switch ...

[HA-TB303]

I had the same issue.

[Koenkk]

Are you using a CC2530/CC2531 router?

[HA-TB303]

I had this issue using a cc2530 coordinator, 2 osram smart plugs as routers and no cc2530 router. When removing the osrams, they would join again, without the “allow joining” on.

[antti365]

I am using CC2531 stick coordinator, there are no CC2531 routers on the network.

[HA-TB303]

zigbee2mqtt:info 2019-2-17 10:29:36 Successfully removed 0x7cb03eaa00a7XXXX
zigbee2mqtt:info 2019-2-17 10:29:36 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"device_removed","message":"0x7cb03eaa00a7XXXX"}'
zigbee2mqtt:warn 2019-2-17 10:29:36 Message without device!
zigbee2mqtt:info 2019-2-17 10:29:38 Connecting with device...
zigbee2mqtt:info 2019-2-17 10:29:38 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
zigbee2mqtt:info 2019-2-17 10:29:38 Connecting with device...
zigbee2mqtt:info 2019-2-17 10:29:38 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
zigbee2mqtt:info 2019-2-17 10:29:38 Connecting with device...
zigbee2mqtt:info 2019-2-17 10:29:38 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
zigbee2mqtt:info 2019-2-17 10:29:38 Connecting with device...
zigbee2mqtt:info 2019-2-17 10:29:38 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
zigbee2mqtt:info 2019-2-17 10:29:38 Connecting with device...
zigbee2mqtt:info 2019-2-17 10:29:38 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
zigbee2mqtt:info 2019-2-17 10:29:38 Connecting with device...
zigbee2mqtt:info 2019-2-17 10:29:38 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
zigbee2mqtt:info 2019-2-17 10:29:38 Connecting with device...
zigbee2mqtt:info 2019-2-17 10:29:38 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
zigbee2mqtt:info 2019-2-17 10:29:39 Connecting with device...
zigbee2mqtt:info 2019-2-17 10:29:39 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
zigbee2mqtt:info 2019-2-17 10:29:39 Connecting with device...
zigbee2mqtt:info 2019-2-17 10:29:39 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"connecting with device"}'
zigbee2mqtt:info 2019-2-17 10:29:39 Device incoming...
zigbee2mqtt:info 2019-2-17 10:29:39 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"device incoming"}'
zigbee2mqtt:info 2019-2-17 10:29:39 New device with address 0x7cb03eaa00a7XXXX connected!
zigbee2mqtt:info 2019-2-17 10:29:39 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"device_connected","message":"0x7cb03eaa00a7XXXX"}'

[antti365]

@Koenkk Upon reflection, I came to the conclusion that there is confusion and misunderstanding with the remove and ban options. As I understand it, when deleting, a device is removed from the zigbee2mqtt database. But the device itself knows the encryption keys, pan id, channel number, etc. and calmly connects to the network again.
Take for example the z-wave network - the device also has all the information about the network, BUT, if it is removed from the database of the coordinator, it alone will never go back there. How not to get there, and no random neighbor device. The z-wave coordinator has the following options - inclusion in the network, exclusion from the network, remove node.
Remove node - removes the device from the database of the coordinator. The device is removed from the database and cannot be re-added to the network before it is excluded from the network.
Exclusion from the network - the mode is turned on simultaneously on the coordinator and on the device, approximately the same happens on the zigbee device when pressing the pairing button. You can exclude any devices, even those that were previously on another network.
Inclusion in the network - adding a previously excluded device to our network, the mode is activated on the coordinator and on the device by the pairing button.
Previously, I had an Ikea hub, as far as I remember, there, too, when removing a device from the hub, it itself could not get back.
In our case, you need to rethink the function remove, so that the remote device from the zigbee2mqtt database could not get back into the network if several conditions are not met:
The device can be added to the network ONLY if permit_join = true (Inclusion) and the device is excluded from the network (not necessarily ours), if false, any connection attempts should be ignored.
Then the ban option will be completely unnecessary.
I don’t know if I was able to explain my thoughts with my poor English.

[bebor001]

I've got the same issues. Also it appears to me as if i couldn't change the permit_join-option at all. If i change it via the mosquitto publisher it wouldn't change at all and if i try changing it by hand, it will switch back to true a few seconds later. Where is my mistake and what's the point i'm not getting ? Any answers are highly appreciated.

[Koenkk]

@antti365 this problem is not something that can be easily be solved by making some changes to zigbee-shepherd, as long as the device has the network key, it can communicate with other devices in the network.

What permit_join basically is doing, if enabled, the network key can be shared with devices, but as this device already has the key, it's useless.

I tried to factory reset the TRADFRI bulb by the resetFactDefault command, but the bulb doesn't respond to this.

I think for the use-case you are describing you basically need to ban the device from the network. If you don't want to do this, the only way to remove a TRADFRI bulb from the network is to factory reset it using the 5x on/off toggling.

[antti365]

@Koenkk OK, but then I still don't understand the logic. What is the command to remove? For what it may be necessary to remove the device from the database, if it appears there again after a while without my desire? And if I make a ban, it will not appear ... so? And if I reset the device, then the ban on it will no longer act?
It’s just that the documentation doesn’t explain in detail what exactly the command does to remove and ban, because of this, such confusion will occur and more ...
My suggestion is to leave one command of the two - remove the delete command and rename the ban to delete, in my opinion it would be more logical, no?

[Koenkk]

@antti365 the behaviour differs per device, the coordinator cannot force a device to forget it's network key with a leave command, some devices do, some (like tradfri) don't.

[bebor001]

@Koenkk Thanks a lot. So I guess I'm just going to ignore the devices in my case. It would have been an option to use the "resetFactDefault"-command, but since you'd mentioned this is also based on the producer, it makes no sense to use it.

[pixeldoc2000]

@Koenkk I have an issus with my Philips Livingcolors Lights (Bloom und Iris).

The devices are joint to my old zigbee network with channel 14 (which is not a default zigbee lightning network channel) where i can still control them without rejoin them. Now I want to join them to my new network different channel 15 and network_key.

The problem ist I can't reset the Livingcolor Devices still on channel 14 with the corresponding Livingcolor Remote. I guess it's because the Livingcolor Remote only use the default zigbee lightning channels like 11, 15, ... The Livingcolor Devices does not have a reset button.

I tried zigbee2mqtt/bridge/config/remove on the old network but soon realizied the command only removes the device from the zigbee2mqtt config and does not "reset" the zigbee device (monitored with sniffer). (Wiki Updates needed?)

How to send resetFactDefault to the Livingcolor Devices?
Does anybody know if Philips devices support the command at all?

Looks like its almost impossible to disassemble the devices to look for a uart connections or any other facility to reset the device config other than via zigbee.

[Koenkk]

@pixeldoc2000 did you follow the instructions from http://www.zigbee2mqtt.io/getting_started/pairing_devices.html#philips-hue ?

[pixeldoc2000]

@Koenkk Of cause, I wrote the "Philips Living Colors IRIS (Friends of HUE)" part myself ;-)

If i do the regular reset/pairing with the Philips LivingColors Remote it sends broadcast only to the zigbee lightning channels 11, 15, 20 and 25. I verified it with my sniffer.

As my Philips LivingColors Devices are on Channel 14 i'm not able to reset the devices at least with this remote, maybe TRADFRI is different?

If resetFactDefault maybe not possible with this device, how about changing channels?

[Koenkk]

To test if factor reset works,

Add tz.factory_reset to the toZigbee section of your device in https://github.com/Koenkk/zigbee-shepherd-converters/blob/master/devices.js.

Now send to: zigbee2mqtt/[DEVICE_FRIENDLY_NAME]/set payload {"reset": ""}

[pixeldoc2000]

In the mean Time i found some answers elsewhere:
https://community.smartthings.com/t/faq-exact-remote-needed-to-reset-hue-bulbs-uk/27796/74
The gist of it is:

• My Philips Living Colors Remote Gen 3 only use/scan the default ZLL Channels 11, 15, ... - So no luck resetting my Living Colors as long as they are on Channel 14 with this Remote
• The Philips Living Colors Remote Gen 2 and (older?) use/scan all Zigbee Channels - Should reset my Living Colors on Channel 14
• There are other ZLL Remote which also suppose use all Zigbee Channels (Lutron connected bulb remote/ TRADFRI?)

@Koenkk sadly no response or effect on ether one of my Living Colors Devices:
zigbee2mqtt:debug 2019-2-27 21:06:35 Received MQTT message on 'zigbee2mqtt-test/philips_livingcolors_bloom_1/set' with data '{"reset": ""}' zigbee2mqtt:info 2019-2-27 21:06:35 Zigbee publish to device '0x001788010330d95b', genBasic - resetFactDefault - {} - {"manufSpec":0,"disDefaultRsp":0} - null

EDIT:
I'm not quite shure where to add tz.factory_reset to devices.js actually. Because the Devices have extend: hue.light_onoff_brightness_colorxy -> generic.light_onoff_brightness_colorxy <- there?
https://github.com/Koenkk/zigbee-shepherd-converters/blob/master/devices.js Line 34

Devices are "LLC010" and "LLC011"