If I tried to read an attribute, it does not make the device reachable. The reading does not terminate
Ok, so it s realy like a zigbee disconnection.
There is some shortcut to use in deconz (“L” to make the device leave and rejoin, “F5” that refresh the node) but for me you will have a timeout error.
You have lot of distance between the device and the first router ? what is this router ?
I don’t think it s a setting issue, else there would be more people with this issue ?
The device is very close to an ikea dimmable light (around 4m) and at 10m of the Deconz dongle. I will probably remove the two consumption devices (ZHAConsumption) and just let one device (ZHAPower) in the DDF. Then I will see if I have still the problem.
Just by curiosity you can enable LQI on deconz for some minuts to have values on connexion lines.
I did it: 243/59 on the link between the ZLinky and the Deconz dongle and 68/155 between the ZLinky and the IKEA dimmable light.
Hello,
New here and a bit lost with DDF.
I search a DDF json for my Lixee as bellow:
Standard + HPHC + Production
Thanks a lot
@ngranier Hello, There is one but not yet tested, if you can test it for adjustement ?
{
"schema": "devcap1.schema.json",
"manufacturername": "LiXee",
"modelid": "ZLinky_TIC",
"product": "ZLinky_TIC Standard mode with production and HPHC",
"sleeper": false,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_POWER_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0b04"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/current",
"refresh.interval": 300,
"read": {
"at": "0x0508",
"cl": "0x0b04",
"ep": 1,
"fn": "zcl"
},
"parse": {
"at": "0x0508",
"cl": "0x0b04",
"ep": 1,
"eval": "if (Attr.val != 65535) { Item.val = Attr.val; }"
}
},
{
"name": "state/lastupdated"
},
{
"name": "state/power",
"refresh.interval": 300,
"read": {
"at": "0x050f",
"cl": "0x0b04",
"ep": 1,
"fn": "zcl"
},
"parse": {
"at": "0x050f",
"cl": "0x0b04",
"ep": 1,
"eval": "if (Attr.val != -32768) { Item.val = Attr.val; }"
}
},
{
"name": "state/voltage",
"refresh.interval": 300
}
]
},
{
"type": "$TYPE_CONSUMPTION_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0702"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/consumption",
"refresh.interval": 300,
"read": {
"at": "0x0100",
"cl": "0x0702",
"ep": 1,
"fn": "zcl"
},
"parse": {
"at": "0x0100",
"cl": "0x0702",
"ep": 1,
"eval": "Item.val = Attr.val"
}
},
{
"name": "state/consumption_2",
"refresh.interval": 300,
"read": {
"at": "0x0102",
"cl": "0x0702",
"ep": 1,
"fn": "zcl"
},
"parse": {
"at": "0x0100",
"cl": "0x0702",
"ep": 1,
"eval": "Item.val = Attr.val"
}
},
{
"name": "state/production",
"refresh.interval": 300,
"read": {
"at": "0x0001",
"cl": "0x0702",
"ep": 1,
"fn": "zcl"
},
"parse": {
"at": "0x0100",
"cl": "0x0702",
"ep": 1,
"eval": "Item.val = Attr.val"
}
},
{
"name": "state/lastupdated"
}
]
},
{
"type": "ZHAAlarm",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0xff66"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/alarm",
"refresh.interval": 30,
"read": {
"at": "0x0005",
"cl": "0xff66",
"ep": 1,
"fn": "zcl"
},
"parse": {
"at": "0x0005",
"cl": "0xff66",
"ep": 1,
"eval": "Item.val = Attr.val > 0 ? true : false",
"fn": "zcl"
},
"default": false
},
{
"name": "state/lastupdated"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0702",
"report": [
{
"at": "0x0000",
"dt": "0x23",
"min": 1,
"max": 300,
"change": "0x00000001"
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0B04",
"report": [
{
"at": "0x0505",
"dt": "0x21",
"min": 1,
"max": 300,
"change": "0x00000001"
},
{
"at": "0x0508",
"dt": "0x21",
"min": 1,
"max": 300,
"change": "0x00000001"
},
{
"at": "0x050F",
"dt": "0x21",
"min": 1,
"max": 300,
"change": "0x00000001"
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0xFF66",
"report": [
{
"at": "0x0005",
"dt": "0x21",
"min": 1,
"max": 300,
"change": "0x00000001"
}
]
}
]
}
But there is a problem, what is your third app ?
It’s possible new fields are not supported by it, can check the complete json in phoscon / help / API Infortmation / sensors
@smanar just a question: I am currently in History mode, would it be better to ask to move to Standard mode ?
By defaut it s historic mode, better compatibility
Le mode historique assure ainsi une compatibilité des équipements connectés lors du remplacement d’un compteur électronique par un compteur Linky. Le mode « standard »*. Il transmet les données du mode « historique » à un débit plus élevé, dans un format différent, et des données supplémentaires
For me standard is reserved to special mode
le mode historique ne fonctionne qu’avec les abonnements classique (BASE, heures pleines/creuses, bleu blanc rouge). Pour tous les abonnements particuliers (ex heures super creuses), il est obligatoire de passer le Linky en mode standard.
Actuellement, l’appareil fonctionne avec le mode Historique et standard du compteur Linky.
Il permet de gérer tous les abonnements en mono ou triphasé et le mode production (uniquement en mode standard)
Thanks for the info, but with the ZLinky_TIC, would it be better to use the standard mode ? More stable ?
IDK, on “historic” mode the device receive more data from the linky, but we can set the report we want from it to the zigbee network, so I don’t think it have an impact on the stability.
Is someone else have tried the 2 mode ?
Hi @Smanar,
I installed v2.16.1 and I had less issues than with previous versions. I just have one question: what is the purpose of the circle on the left part of the device displayed by Deconz (the one in blue in the following figure):
When my Zlinky does not communicate, this circle is flashing blue and grey rapidly. I read again the manual and did not see an explanation of the meaning of this circle.
Thanks.
You have it ^^, but not in the manual, we need to hunt documentation on deconz
Thanks for the pointer. Meanwhile, the led has stopped flashing and the communication is restored. But as I said, it seems that I have less issues with the latest version. In one week, I did not pair again my ZLinky, only the communication stopped for a couple of hours, especially early in the morning:
You have upgraded the firmware too ?
Because I don’t remember new features that can help for your issue on deconz code.
On last firmware
Improve direct child node handling in new RaspBee II and ConBee II firmware version 0x26780700
No, I did not. The version I have is 26720700. I will do the upgrade right away! Thanks again.
Was just a question ^^, I haven’t say this firmware is better for you.
Upgrade is done. Let see how the ZLinky behaves now. On the positive side, a lot of progress has been done thanks to your help since I bought the device. Thanks again.
@gd35 is your ZLinky power supply has been fixed by @fairecasoitmeme ?
I received my Zlink fixed (by adding a condensator on the hardware) since few days , and for the moment, no disconnection has occured …
Bye