df0b7e9c63
This patch separates the transactionSequenceNumber used for sending from the one received. According to the specification, the transactionSequenceNumber is not meant to equally increase on both ends, but instead really just be a "random" number which allows to match a reply to a request. Syncing them on both ends has the outcome to increase the likelyhood of collisions if a device sends a notification at the same time we send a request and thus even may wrongly interpret that incoming command as a reply to the request. In fact, ideally TSNs for outgoing messages would stay away as far as possible from incoming ones. The old code additionally had the problem that it would re-use the last received TSN for outgoing requests, given it used a post-increment when reading m_transactionSequenceNumber after setting it to the last received TSN. The new code will use a single static upcounting TSN for all outgoing requests but will still allow overriding it with a custom TSN of for some reason a certain device requires a specific TSN (apparently those exist). It will not do anything with incoming TSNs but forward them now to the application layer which may decide to use it match its own transactions or to deduplicate packets. This allows fixing the issue in nymea that remote controls sometimes produce duplicate pressed events (seen most often with the Tradfri Symfonisk) by discarding commands that didn't increase the TSN.
nymea-zigbee
This repository contains the nymea-zigbee library and tools.
Supported hardware
Depending on your available hardware following gateway modules are supported
NXP
Note: the firmware erquires an entire rework and implement the APS layer
- JN5168 (SoM)
- JN5169 (USB Stick)
deCONZ
- ConBee
- RaspBee
- ConBee II
- RaspBee II
Hidden base groups
Each sensor/remote cluster will be bound automatically to the sensors group in order to receive commands from the device. The lights group can be used to switch all lights within the network with one command.
- Sensors:
0xfff0 - Light:
0xfff1