Hi @Egglestron
Are you in History mode or Standard mode ? I would like to know if this issue appears also to those who use the standard mode.
Hi @Egglestron
Are you in History mode or Standard mode ? I would like to know if this issue appears also to those who use the standard mode.
@gd35 Iâm in Standard mode!
@Smanar My refresh.interval
is indeed set at 300 sec. I just donât get what is meant by âon peut en crĂ©er 20 maximumâ, but my reporting config is now set to 30 to 300 sec (with reportable change at 10) for the Apparent power attribute.
Weâll see how it goes!
âon peut en crĂ©er 20 maximumâ mean for me the number of attributes we can bind on the same device, and we are under. (itâs the last part on the DDF)
@Egglestron : so the mode does not have an impact on this issue. On my side, I found that the communication stops every 24h around the same time for a couple of hours.
Does it work with deconz on jeedom ?
Depend of your contract, the historic+mono+base will work natively, the HP/HC will need probably some action from you, because of the new command used like state/consumption2
are probably new for jeedom.
Ok Iâll try this and ask jeedom team. Thanks,
Hello there, Iâm unable to add this device in phoscon.
Iâm running latest version (2.17.01-debian-buster-stable) and added DDF from deconz-rest-plugin/devices/lixee at lixee_ddf · Smanar/deconz-rest-plugin · GitHub
But even after Iâm trying to reassociate it, no luck.
What am i missing ?
All DDF are with âDraftâ Status, you need to choose the one you need according to your installation and chnage the status to âGoldâ using the DDF editor or a text editor.
Hi there,
I setup my zlinky a couple months, I was in historical without solar panels back then. Now Iâm in standard mode and with solar panels. Two things:
Thanks !
Hello, There is 2 differents DDF for standard and historical.
You have switched them ?
If yes, can you give me the DDF you are using ATM (the file name)
And say me
Perhaps need to create a new one, there is only 3 availables ATM.
There is this one Add DDF for the Zlinky_TIC device by Smanar · Pull Request #5969 · dresden-elektronik/deconz-rest-plugin · GitHub
For Standard / mono / Base
And none have the production yet, I m waiting for an user confirm me itâs working before adding it.
Just confirm me the DDF I will add it the production to test.
Here you have a standard HP + Production but not tested LiXee ZLinky_TIC DDF File - #104 by Smanar
I am using devices/lixee/zlinky_tic_standard_mono_base.json and yes I am standard (to get production) base mono.
The weird thing is that 0x0000 is a number not seen on the real Linky device and is a sum of 0x0100 and 0x0102. My consumption seen from Linky is the same number than 0x0100 but I am not with HP/HC contract but Base. I was HP/HC a year ago.
I can see my consumption on 2 others clusters.
On Lixee special cluster I see a production/injection line but with value 0. On my Linky I can see more than 60Kva. I did not find this value anywhere while searching in deconz gui.
Will try the DDF file HP + production asap
Meanwhile I read fairecasoitmeme Readme https://github.com/fairecasoimeme/Zlinky_TIC#synthÚse-développeur and this seems normal.
In Historique mode 0x0100 and 0x0102 are HC HP but in standard 0x0100 is total energy. It is just that wording in deconz gui only match Historique modeâ not standard mode.
I will try to read 0x0001 at home to get production.
Yep exactly, it s the 0x0001 for production, can try this DDF
{
"schema": "devcap1.schema.json",
"manufacturername": "LiXee",
"modelid": "ZLinky_TIC",
"product": "ZLinky_TIC Standard+Base+production",
"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": "0x0000",
"cl": "0x0702",
"ep": 1,
"fn": "zcl"
},
"parse": {
"at": "0x0000",
"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": 300,
"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": "0x0B04",
"report": [
{
"at": "0x0508",
"dt": "0x21",
"min": 60,
"max": 300,
"change": "0x00000001"
},
{
"at": "0x050F",
"dt": "0x21",
"min": 60,
"max": 300,
"change": "0x00000001"
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0702",
"report": [
{
"at": "0x0000",
"dt": "0x23",
"min": 60,
"max": 300,
"change": "0x00000001"
},
{
"at": "0x0001",
"dt": "0x23",
"min": 60,
"max": 300,
"change": "0x00000001"
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0xFF66",
"report": [
{
"at": "0x0005",
"dt": "0x21",
"min": 60,
"max": 300,
"change": "0x00000001"
}
]
}
]
}
In Historique mode 0x0100 and 0x0102 are HC HP but in standard 0x0100 is total energy. It is just that wording in deconz gui only match Historique modeâ not standard mode.
I m not sure to understand but in this DDF I m reading the attribute 0x0000 âEnergie active soutirĂ©e totaleâ
Look at https://github.com/fairecasoimeme/Zlinky_TIC#synthÚse-développeur 0x0100 description, it says that in Historique mode it will provide HC or Base total energy but in Standard mode it will provide EASF01 which is Base from your current provider. I think in Standard mode 0x0000 might not be what you want, because it is the sum of EASF01 EASF02 ⊠I my case the value I read on my Linky matches EASF01 aka 0x0100
Look at my values : 10.048.259 is the meaningful value for me. I read 10048Kwh on my Linky. I do not know why I have a value at 0x0102 (2.962.448). Maybe it is to store value when changing provider, or old HP value from the time I was with HPHC⊠In any case, the 0x0000 value has no sense here.
Weirder I have no value at 0x0001. Still 0, but Linky shows a production of ~60Kwh⊠Where did it goes?
Regarding the production, maybe it is not send on TIC yet because I did not complete all the paperwork. If I read 0xFF66 0x0300 it says 1 which is " 1 - Mode standard monophasé " I think I need to be on mode " 5 - Mode standard monophasé producteur"
Iâm on a triphasĂ© contract, I will see if I can edit the DDF and made on a new one for this.
To be continued
@martintamare
I donât find again the DDF on test for TriphasĂ© but you can use for current
@JSteunou Itâs like you have not yet the standard mode ? 0x0100 and 0x0102 are 2 index, used for exemple for HP/HC mode, so its normal the total in 0x0000 is the sum for me (and can be a way to explore if you was in HPHC previously).
And strange you canât see the value 0x0102 somewhere on the linky âŠ