Closed pipiche38 closed 1 year ago
Here attached is a full log.
The device short id is: 9cd0 The device mac@ is: a4c1380e66e37fe2
The command that we have tried to send our add to group membership
A message is received from this device at 2022-10-20 19:55:11,231 and a bit later a commande is send and finished with Failure
The network is a large network 29 ZR + 38 ZED the coordinator is a shield elelabs
I would like also to highlight that we have tried to disable the source_routing , and we see the same behaviour
The device itself is Switch without neutral https://www.amazon.fr/MOES-Interrupteur-intelligent-installation-condensateur/dp/B096W232HT/ref=mp_s_a_1_5?crid=2RKFTPAN25D7I&keywords=moes%2Bzigbee&qid=1666285837&qu=eyJxc2MiOiI1LjQxIiwicXNhIjoiNC41NyIsInFzcCI6IjMuNTIifQ%3D%3D&sprefix=moes%2Bzigbee%2Caps%2C114&sr=8-5&th=1&psc=1
Most tuya "without neutral" is sleepers or not router devices and is not having the radio on all the time. Sniff the node description from the device then paring it and you is getting the information.
If its sleeping then try waking it up then sending commands to it.
I do agree with you that without neutral is not a router. But at least this should do polling in order to receive command. This is a switch and from the documentation it is actionnable from the Tuya app.
I know other Switch without neutral which works well.
"normal" tuya devices is having Silabs chips but new can having Telink Semiconductor
chips with one buggy Zigbee stack.
I have one TS0004 (quad switch module) that is working very well and is one router but some other devices with the chip is acting very strange.
Use https://macvendors.com/ for checking the chip with the MAC / IEEEE.
I would be happy to take that. But unfortunately similar behaviour is happening with SonOff SBMINI (which is also without neutral) Basically in the sniffer I see a lot of Route Request as well as Route Request but no commands going out
Ok, I started to have a better understanding of what is happening on its network. And in fact the Sonoff as the Tuya TS0011 are nicely sending their Data Request. However for whatever raison, it is going through a router, which is not sending the information back to the coordinator or to the next hop
So I do confirm that even the Tuya which is the brand you are mentioning works well, when the router in between is forwarding the Data request
We are having an issue with a device which is sending report without any trouble to the coordinator, but the sending command from coordinator to the device is faling.
Here is the Configuration when starting.
EZSP Configuration: {'device': {'path': '/dev/ttyAMA0', 'baudrate': 115200, 'flow_control': 'software'}, 'network': {'channel': 15, 'pan_id': None, 'tc_link_key': 5a:69:67:42:65:65:41:6c:6c:69:61:6e:63:65:30:39, 'tc_address': None, 'extended_pan_id': None, 'update_id': 0, 'key_sequence_number': 0, 'key': None, 'channels': <Channels.CHANNEL_25|CHANNEL_20|CHANNEL_15: 34635776>}, 'ezsp_config': {'CONFIG_MAX_END_DEVICE_CHILDREN': 0}, 'topology_scan_enabled': False, 'handle_unknown_devices': True, 'source_routing': True, 'backup_enabled': True, 'backup_period': 1, 'tx_power': 15, 'ezsp_policies': {}, 'database_path': None, 'topology_scan_period': 240, 'max_watchdog_failures': 4, 'topology_scan_skip_coordinator': False, 'ota': {'inovelli_provider': False, 'otau_directory': None, 'ikea_provider': False, 'salus_provider': False, 'ledvance_provider': False}}