#Zigbee2mqtt chaos

1 messages · Page 1 of 1 (latest)

hushed mesa
#

Hey,
my Z2M started behaving completely unpredictable a couple of days ago. Devices work or they dont, the Zigbee2mqtt Bridge State keeps going offline in intervals of 5min. - 1h, Lamps wont turn on and then do MINUTES later and i keep getting a million "publish X to X failed" errors.
It used to work before until my Coordinator switched to a different USB interface (e.g. from /ttyUSB0 to /ttyUSB1 and back). I then used the by-id. Now the adapter does no longer disconnect permanently but it disconnects and reconnects randomly.

distant tundra
#

What coordinator?

#

Did you follow all the standard advice when setting up?

hushed mesa
#

Sonoff Zigbee 3.0 USB Dongle Plus
It worked for half a year
What standard advice?

distant tundra
#
  1. Use a USB extension cable
  2. Pick a channel clear of WiFi, don't use the default
  3. On a Pi consider a powered USB hub
hushed mesa
#

I did try an extension cable, that didn´t change anything
I did pic a wifi channel that should be good, will recheck thatt
Can this be a voltage issue? And if so: Can this happen after it worked for six month and then start missbehaving?

distant tundra
#

Keep in mind that Zigbee channel numbers aren't the same as WiFi channel numbers

hushed mesa
#

I know

distant tundra
#

Could be voltage if you've recently added some other USB device

#

The only other thing to try on a Sonoff P is to re-flash the firmware

hushed mesa
#

It's the only USB Device on that Pi. I am using a brick that was in a Box here (I know, I know) but it worked for other aplications and for a long time. I will swap it with a good Power suply and Check if that does the Trick

hushed mesa
#

I swapped the power supply for an official raspberry power supply from a different project and within 2 minutes get the same error messenges again. No difference.

distant tundra
#

Are you using a USB extension cable still? Moving the coordinator away from WiFi, USB 3.0, and Bluetooth?

#

Have you checked to see if your chosen channel is currently clear of WiFi?

hushed mesa
#

Yes i am currently using an extension cable. There are no sources of wifi or BT or USB3 devices next to the coordinator.
There are no real "clear" channels as my neighbors are using wifi too of course but i am on Zigbee channel 15 wich should be the least noisy currently (there is wifi of -80db) or lower around that channel)

distant tundra
hushed mesa
#

And here is an example log from Z2Mhttp://pastie.org/p/2K8FOLk4J0eDUXaXuZdDpk

distant tundra
#

You have 3 WiFi signals overlapping 15, and at a pretty high signal strength

hushed mesa
#

It keeps changing. But i will try a different channel.

#

I will collect my strenght and do yet another repairing session in a couple of hours and then report back here after i swapped everything to channel 20. I hope that helps

#

Also I noticed: Some Devices react instantly and reliabble and others I can Turn on without any Problem but not off or vice versa

distant tundra
#

What devices are in the mesh - exactly

#

Some are known to cause problems, Osram, some Sonoff, etc

hushed mesa
#

4 OSRAM AC10691
2 Xiaomi DJT11LM
1 IKEA E1524/E1810
1 IKEA E1812
2 IKEA ICPSHC24-10EU-IL-1
1 IKEA ICPSHC24-30EU-IL-1
9 Xiaomi MCCGQ11LM
1 Xiaomi SJCGQ11LM
2 SONOFF SNZB-01
6 TuYa TV02
7 Xiaomi SJCGQ11LM
1 Xiaomi WXKG15LM
3 Müller Licht 45728
1 Müller Licht 45730
1 Philips 929002469202
4 LEDVANCE 4058075208391

hushed mesa
#

Okay, since i swapped the Power supply, at least the coordinator stopped going offline... maybe if i just repair the misbehaving devices now...

distant tundra
#

Are the OSRAM Zigee 3.0 or 1.2?

#

Only the 1.2 devices are known bad, and by bad read avoid at all costs

hushed mesa
distant tundra
#

Z2M gives you a hint in the Device state page

# 
        "zclVersion": 3
hushed mesa
# 
    "last_seen": "2023-09-07T15:35:35.420Z",
    "linkquality": 96,
    "state": "OFF",
    "update": {
        "installed_version": 1061121,
        "latest_version": 1061121,
        "state": "idle"
    },
    "update_available": null
}```
#

or it doesn´t

hushed mesa
mortal spruceBOT
#

@hushed mesa When using Discord's Reply feature it defaults to pinging the person you reply to, which can get frustrating for the target. Use Shift + click on the Reply option, or click @ ON to @ OFF to stop this - on the right side of the compose bar.

You have to change this every time (thank the Discord devs for that).

distant tundra
#

Never not seen that reported... wonder what setting you missed

# 
{
    "battery": 82,
    "battery_low": false,
    "contact": false,
    "device": {
        "applicationVersion": 8,
        "friendlyName": "bathroom_door",
        "hardwareVersion": 0,
        "ieeeAddr": "0x54ef4410004c75b4",
        "manufacturerID": 4447,
        "manufacturerName": "LUMI",
        "model": "MCCGQ14LM",
        "networkAddress": 36158,
        "powerSource": "Battery",
        "stackVersion": 2,
        "type": "EndDevice",
        "zclVersion": 3
    },
    "last_seen": "2023-09-07T15:34:25.474Z",
    "linkquality": 109,
    "power_outage_count": 0,
    "tamper": false,
    "update": {
        "installed_version": -1,
        "latest_version": -1,
        "state": null
    },
    "update_available": null,
    "voltage": 2973
}```
hushed mesa
#

the state page of none of my devices is that long

distant tundra
#

Then something strange is going on

#

What does your Z2M config look like

hushed mesa
#

Can the "known bad" devices cause problems with OTHER devices? Because its other manufacturers Bulbs, IKEA power supplys and other devices that fail

distant tundra
#

Yes

hushed mesa
#

ops

# 
devices:
  - devices.yaml
groups:
  - groups.yaml
homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  user: addons
  password: XXX
  server: mqtt://core-mosquitto:1883
serial:
  port: /dev/ttyUSB0
advanced:
  log_level: warn
  pan_id: 34575
  channel: 15
  network_key:
XXX
  availability_blocklist: []
  availability_passlist: []
  log_syslog:
    app_name: Zigbee2MQTT
    eol: /n
    host: localhost
    localhost: localhost
    path: /dev/log
    pid: process.pid
    port: 514
    protocol: udp4
    type: '5424'
  transmit_power: 20
  homeassistant_legacy_entity_attributes: false
  legacy_api: false
  legacy_availability_payload: false
  last_seen: ISO_8601
device_options:
  legacy: false
blocklist: []
passlist: []
queue: {}
frontend:
  port: 8099
experimental: {}
distant tundra
# 
advanced:
  cache_state: true
``` are the only meaningfully different settings on mine
#

Oh, and

homeassistant:
  legacy_entity_attributes: true
hushed mesa
#

no difference in the status page

#

@distant tundra Some devices just always work all the time perfectly. Do you think i should just change the channel and repair everything or keep looking for possible Bad devices first? I do not fancy repairing everything as it is a pain in the A and takes forever and very often the IDs are messed up afterwards, but i will do that if i have to.

#

Also i tryed redoing just one because i thought repairing just the missbehaving ones might work but it won´t pair now

distant tundra
#

It's only you and I in this thread, tagging me is unnecessary, and obnoxious