Support request for BTicino DIN power consumption module

meco489 commented 4 years ago

Hi, I have installed a RaspBee for my home automation. I can connect some BTicino products, using Legrand integration .... under the list of functioning products. I can't connect a DIN module for power measurement. I attach below the screenshots. Thanks in advance and congratulations for the work you are doing. Domenico

Working Products:

BTicino K4003C equal to Legrand 067773
BTicino 3584C equal to Legrand 064888
BTicino K4531C equal to Legrand 067775

Non-functioning products:

BTicino F20T60A

SwoopX commented 4 years ago

It must be Phoscon. Should not really matter, what you use for the search.

rotragit commented 4 years ago

OK, this is the situation at the moment. In the db it's listed in devices but not in sensors nor in nodes. Istantanea_2020-03-24_16-40-15

If I delete the node, reset the bTicino module and pair again, the result is the same. Should I expect to find a line in sensors?

Smanar commented 4 years ago

Now it's fine, don't touch your network ^^.

And yes, even it don't work, you need to have a new sensor.

Can you show the JSON of your device, the light one, and if you find it the sensor one.

There is many way to have itn but the easier way is using a web browser

http://IP:PORT/api/API_KEY/lights/
http://IP:PORT/api/API_KEY/sensors/

You have few device, so it will be easy to see them (or it if the sensor not working).

If you select the second circle in the node, you have "Consumption awareness device" ?

Can you compare your device with this one too (the first table, you will have more information on the second one)

rotragit commented 4 years ago

Thereis not in lights and not in sensors :-( and not in the tables on the sqlite3 db...

{"1":{"etag":"ee2bced91e6b123a6cc72ecd2e3a8dc0","hascolor":false,"manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E14 W op/ch 400lm","name":"corridoio","state":{"alert":"none","bri":254,"on":true,"reachable":false},"swversion":"1.2.214","type":"Dimmable light","uniqueid":"08:6b:d7:ff:fe:01:fe:13-01"},"2":{"etag":"ee2bced91e6b123a6cc72ecd2e3a8dc0","hascolor":false,"manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E14 W op/ch 400lm","name":"Dimmable light 2","state":{"alert":"none","bri":254,"on":true,"reachable":false},"swversion":"1.2.214","type":"Dimmable light","uniqueid":"08:6b:d7:ff:fe:07:6b:58-01"},"3":{"etag":"ee2bced91e6b123a6cc72ecd2e3a8dc0","hascolor":false,"manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E14 W op/ch 400lm","name":"Dimmable light 3","state":{"alert":"none","bri":254,"on":true,"reachable":false},"swversion":"1.2.214","type":"Dimmable light","uniqueid":"08:6b:d7:ff:fe:2f:20:99-01"},"4":{"ctmax":65535,"ctmin":0,"etag":"ee2bced91e6b123a6cc72ecd2e3a8dc0","hascolor":true,"manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E27 WS opal 1000lm","name":"Erica","state":{"alert":"none","bri":254,"colormode":"ct","ct":370,"on":true,"reachable":false},"swversion":"2.0.022","type":"Color temperature light","uniqueid":"cc:cc:cc:ff:fe:e9:a6:a8-01"},"6":{"etag":"469a757bb9e213525e55e09012b0db4f","hascolor":false,"manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E27 WW 806lm","name":"Cucina","powerup":7,"state":{"alert":"none","bri":254,"on":true,"reachable":true},"swversion":"2.1.022","type":"Dimmable light","uniqueid":"ec:1b:bd:ff:fe:31:95:fe-01"},"7":{"etag":"83955565fe6c3d29d6419f5172eb95e2","hascolor":false,"manufacturername":"dresden elektronik","modelid":"ConBee II","name":"Configuration tool 7","state":{"reachable":true},"swversion":"0x264a0700","type":"Configuration tool","uniqueid":"00:21:2e:ff:ff:05:03:6f-01"}}

rotragit commented 4 years ago

Yes, if I select the second circle in the node, I have "Consumption awareness device". Istantanea_2020-03-24_18-09-25

Smanar commented 4 years ago

Have you used phoscon for inclusion ?

You can force the API device creation with a tips

set phoscon in permit join
in the Node Info panel, read the Basic cluster attributes (select the Cluster "Basic" 0000, on the new panel there is a button "read" a the bottom)

And ofc without reseting/deleting the device.

rotragit commented 4 years ago

Bingo!

Yes, I used phoscon for inclusion. With your tips now I see the sensor also in HA.

(Thank you)E+1000 :-)

Smanar commented 4 years ago

NP, IDK what happened, but it s like the device was included but directly with deconz. Perhaps you have a too big permit join duration on it ?

SwoopX commented 4 years ago

@Smanar Just out of curiosity, is there a space before the manufacturer and modelID? I had a quite similar behavior just a couple of days back while trying to have the sensors for a Huawei device created. Reading some basic attributes didn't help, so I had to implement a rather exotic change...

@rotragit Glad it finally worked out.

Smanar commented 4 years ago

@SwoopX heyyyy, You are right (good eyes again ^^), I m looking in wireshark there is 0x20 before the string for both and I think all legrand device

But It work when I do

if (sensor->modelId() == QLatin1String("Dimmer switch w/o neutral") ) then ...

Perhaps some functions trim the string (but not all) ?

For exemple the string is trimmed in the API but not in deconz.

Edit

void LightNode::setModelId(const QString &modelId)
{
    item(RAttrModelId)->setValue(modelId.trimmed());
}
const QString &LightNode::modelId() const
{
    return item(RAttrModelId)->toString();
}

So for me if you are using X->modelId() all will be ok.

SwoopX commented 4 years ago

Hm, good question. It's an assumption.

This is the only place I could spot any impact on the defined modelID at the beginning of de_web_plugin.cpp (first glimpse). And on the bindings...

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/ca72c46fd147dcf5c0b04304a96316d2c97ff477/de_web_plugin.cpp#L7476-L7498

However, it might be that you're right and the strings get trimmed.

rotragit commented 4 years ago

@Smanar , the first ten attempts was done from Phoscon for sure, because only after about ten failures I have investigated on how connect to deconz inside the docker container (I had done some experiments the month before trying to export DISPLAY and running the program from outside but without success, then I understand how to connect using VNC, etc etc). For sure one or two attempts was done trying to join into deconz directly. But I'm sure the last attempt (and a few before it) was done again in Phoscon because I removed from the db the entry, and I asked what is the correct way to pair the module and you told me: Phoscon. In the dconz the max time to permit join is 254 second. I never put it "always open".

Anyway, I have other two modules like that (I've got three for 25 euro each :-) ). So today I will try with one just "out of the box" and I let you know if the problem is the same...

Smanar commented 4 years ago

Nice, @rotragit

@SwoopX Right, there is nothing in this fonction (to trim const QString &modelId) but I have take a look where the fonction is called

On de_web_plugin, in void DeRestPluginPrivate::addSensorNode(const deCONZ::Node node, const deCONZ::NodeEvent event) we have modelId = sensor->modelId(); or modelId = lightNode->modelId(); then if (!isDeviceSupported(node, modelId))

So for me it's ok

but in void DeRestPluginPrivate::delayedFastEnddeviceProbe(const deCONZ::NodeEvent *event) In a rare situation we can have

modelId = attr.toString(); then if (!modelId.isEmpty() && !isDeviceSupported(node, modelId))

Without trim for me, but not sure it concern you ?

rotragit commented 4 years ago

@Smanar , same with the new one out of the box: paired in deconz but sensor is not created. BUT after Phoscon elapses the time for pairing the led on the module is still red.That should mean, as far as I understand, the module doesn't receive an acknowledge message? The red light should mean the module is not paired. After I apply your tips, Phoscon reaches the "Ready" status, the sensor is created, the led on the module turns green and go off as paired.

I confirm the space before the manufacture and model name.

Let me know if I can do some more tests. I can also try to setup a dev environment with an IDE and set a breakpoint in the code. Just tell me witch IDE you usually use and where you think I have to set the breakpoint to understand something. I can delete this module and I have another new to try, anyway.

Smanar commented 4 years ago

Lol, how this device it have a reset buton ?

On other legrand devices, when the led stay red, it mean the inclusion have missed like you said, so this part in normal. But why the device finish the pairing itself when you use the tips .... That is suprising. You have perhaps find a tips for thoses that will have problem with legrand device.

When you reset the device, it join the network (and appear in deconz), use a legrand specific command, and leave if it don't work (and the title becomes grayed in the node), so the led go green or stay red, but after it retry itself many time. So perhaps it have succed on an other tries during the deconz manipulation, because this manipulation can only create API entry for devices already in network, it can't help (normally) for device inclusion, it's for that I have asked you for a device title name in black and not grayed.

Just to be sure, you still have one device not paired ? Try to include it without the tips. I don't think the bug is from the api code, we are using the same for all devices. But rather from precedure or device specificity.

rotragit commented 4 years ago

OK, the third :-) 1) connected to power supply, led is red 2) in Phoscon add sensor, other, 3 minutes, "failed to connect", the led still red, but in deconz the node is present and the title is black.

At this point I long pressed the reset button, the led flashed and become green. With the first one I've done that before your tips, in the second one I did that after your tips. Anyway after your tips Phoscon ends the scanning with "Ready". So it's possible that the pairing is ok for the module when I long press the reset button until the led flash. With first one the led flash was blue and then gone to green, with the second the flash was red then gone to green. Finally led is off on both.

I don't know if is right to long press the reset button, I don't have the bTicino gateway and on the module instruction is written to look at the gateway manual for pairing. So I've just done what made sense to me....

Now, with the third. If I rescan to add a sensor the NWK id changes but the led remains red. Let me know if you want I long press before the tips, or after, or I just stop here at the moment.

I'm not sure that if reset the module and move to another deploy of deconz the behavior is the same as "out of the box". But I can try with one of the first two before "compromising" the "new state" of the third ;-)

rotragit commented 4 years ago

Ok, after a while the node title goes gray in deconz. Don't know after how many minutes.... something between my previous posting and this one....

Smanar commented 4 years ago

Ok, after a while the node title goes gray in deconz. Don't know after how many minutes.... something between my previous posting and this one....

Yes, if the led is still red, the pairing is not finished (the device will leave the network soon, it s something specific to legrand to protect your network from intrusion)

The procedure we are using ATM.

1 long press, around 8s, the led blink before, but you need to stay pressed
The led go red fixe, reset finished.
short press for inclusion
wait for magic

If the led go green > all perfect If the led stay red > fail If the led go purple/blue > bad pairing, can work but not all feature.

When permit join is finished the led go off.
If you set the gateway in permet join again, the led go green or blue again (for all Legrand devices).

On my side, I do long press / short press / wait 10s / long press / short press / wait 10s.

And another thing, when you power on a clean device (out of the box) it try to join immediatly (like philips) without pressing on button, you can see it on deconz, but the pairing will fail. Discussion here > https://github.com/dresden-elektronik/deconz-rest-plugin/issues/883#issuecomment-587515910 He have paired his device without using the reset button, he have failed, but the device can be see in phoscon.

The better method is using phoscon, without the deconz tips to force device creation in API, and playing with short/long press up you have a green led, even if phoscon say "ready". It's not a probleme, because you don't need to delete the API entries (or device), just make the procedure again, deconz will complete missing entries itself.

Tell me if it have worked for the one that stay with the red led, pls.

rotragit commented 4 years ago

ok...well, but it seems to me that the deconz tips is one shot to get the module paired despite the long/short pressing that is fuzzy. I think there are two kind of problems: the first is that the pair process doesn't end correctly until you press the reset button and the led blink, the second is the pair process not always create the sensor expected. Probably a message is missing from the module to deconz or vice versa.... But this discussion will be useful for further users, anyway :-)

SwoopX commented 4 years ago

@Smanar Can you sniff what's been send where you mentioned "short press for inclusion"? Last week, I went quite deeply through the sensor creation parts of the code and spread quite some additional debug output.

One observation I made was that the manufacturer has been read automatically (expected it to be the modelID). Even with changing that, it didn't work out, but that could be related to the cursed sensor I was trying to integrate. Eventually, and that is my theory, the modelID required for sensor creation is not available during the pairing process and consequently fails. Maybe the short press does exactly that (the Xiaomi sensors do). At least, your tip of reading the basic attributes does it.

If anybody is willing or interested to complite the plugin and give it a go for further analysis and investigation, be my guest, I can share it ;)

Smanar commented 4 years ago

the first is that the pair process doesn't end correctly until you press the reset button and the led blink

I don't find that stange on my side ?

the second is the pair process not always create the sensor expected.

Yes, for me it(s that the mystery. But you are the first one with this bug, if we don't count this one that have tried without the reset buton, perhaps it s from the device ...

@SwoopX for a sensor I can understand but this one is a "light", so how it can be in deconz and not the API, there is no whitelist or blacklist for light. He miss the consumption sensor but the light device too. If the pairing process fail for a "light", you will have an incomplete device in API, but you always have one, no ? I need to check if there is something in the code that can prevent deconz add a "light" device in the API.

BTW @rotragit you are using the "add new light" or "add new sensor" feature in phoscon for pairing ?

Legrand have a protection to protect your installation from intrusion, when a device join the network it ask to others device how many time they are online, and if the result is bad, it leave the network itself. This protection make the pairing random, for exemple the device can ask to ikea devices and have bad reponse, or it can ask to conbee but have the answer too late. If you don't have Legrand device, only the conbee can give good answer, but if you alread have legrand devices, you can power cycle them, the pairing will be easier.

On normal use, you just need to power off/ power on the device and start permit join (if you don't need to reset), you don't need short press. On my side I never power off the device, I think the power on trigger the same thing than the short press. But It's same on zigate, you need to short press too, I never see the "normal pairing without touching the reset button" working on deconz, even with power cycle. Phoscon say "ready", the device appear in deconz but leave somes minuts after. And I think the device is created in API too.

The long press is for the reset, useless on a new device (But it seem in @rotragit situation it's something necessary)

BTW another thing I have forget to ask @rotragit, idk if it's too late or not. On your last try you haven't the sensor device in the API, but have you the "light" one ?

Smanar commented 4 years ago

@SwoopX

Ok, so I have tried to sniff packet when I press the button. It s like it try to force the conbee in permit mode.

I have "mgmt permit joining Req (180s)" in broadcast and just after all other Legrand device answer to it "mgmt permit joining Rsp"^^. All Led on Legrand device go to green.

It s perhaps with that the device reconize all other Legrand devices.

Lol, another magic legrand mode, but I think its something specific to them.

rotragit commented 4 years ago

BTW @rotragit you are using the "add new light" or "add new sensor" feature in phoscon for pairing ?

"add new sensor", mainly because I have 10minutes as timeout for lights and 3 minutes for sensors.

The long press is for the reset, useless on a new device (But it seem in @rotragit situation it's something necessary)

If I short press (1 second) nothing happen, if I "long" press (5/6 seconds) the led blinks and the module pairs, if I "very long" press (more then 10 seconds) the module is reset.

BTW another thing I have forget to ask @rotragit, idk if it's too late or not. On your last try you haven't the sensor device in the API, but have you the "light" one ?

No sensor nor light. Really with the first two modules that are now paired I have only the sensor entry but none lght. Here is the json for lights:

{"1":{"etag":"ee2bced91e6b123a6cc72ecd2e3a8dc0","hascolor":false,"manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E14 W op/ch 400lm","name":"corridoio","state":{"alert":"none","bri":254,"on":true,"reachable":false},"swversion":"1.2.214","type":"Dimmable light","uniqueid":"08:6b:d7:ff:fe:01:fe:13-01"},"2":{"etag":"ee2bced91e6b123a6cc72ecd2e3a8dc0","hascolor":false,"manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E14 W op/ch 400lm","name":"Dimmable light 2","state":{"alert":"none","bri":254,"on":true,"reachable":false},"swversion":"1.2.214","type":"Dimmable light","uniqueid":"08:6b:d7:ff:fe:07:6b:58-01"},"3":{"etag":"ee2bced91e6b123a6cc72ecd2e3a8dc0","hascolor":false,"manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E14 W op/ch 400lm","name":"Dimmable light 3","state":{"alert":"none","bri":254,"on":true,"reachable":false},"swversion":"1.2.214","type":"Dimmable light","uniqueid":"08:6b:d7:ff:fe:2f:20:99-01"},"4":{"ctmax":65535,"ctmin":0,"etag":"ee2bced91e6b123a6cc72ecd2e3a8dc0","hascolor":true,"manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E27 WS opal 1000lm","name":"Erica","state":{"alert":"none","bri":254,"colormode":"ct","ct":370,"on":true,"reachable":false},"swversion":"2.0.022","type":"Color temperature light","uniqueid":"cc:cc:cc:ff:fe:e9:a6:a8-01"},"6":{"etag":"6f89081e1309c38c5f26d60e50340aa4","hascolor":false,"manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E27 WW 806lm","name":"Cucina","powerup":7,"state":{"alert":"none","bri":254,"on":true,"reachable":false},"swversion":"2.1.022","type":"Dimmable light","uniqueid":"ec:1b:bd:ff:fe:31:95:fe-01"},"7":{"etag":"83955565fe6c3d29d6419f5172eb95e2","hascolor":false,"manufacturername":"dresden elektronik","modelid":"ConBee II","name":"Configuration tool 7","state":{"reachable":true},"swversion":"0x264a0700","type":"Configuration tool","uniqueid":"00:21:2e:ff:ff:05:03:6f-01"}}

ebaauw commented 4 years ago

how it can be in deconz and not the API, there is no whitelist or blacklist for light.

There is, actually, but on different attributes than for sensors. From memory on Receiver on When Idle (from the device announcement and/or Node Descriptor), Profile ID, Device Type, and (server) clusters (from the Simple Descriptors).

If the pairing process fail for a "light", you will have an incomplete device in API, but you always have one, no ?

Devices (deCONZ::Node instances) are managed by the deCONZ core. In fact, all deCONZ:: objects are. They’re declared in /usr/include/deconz/*.h, which are installed by the deconz-dev package.

Smanar commented 4 years ago

Ok so I was totally wrong, just with cluster list, I think it can be a reason for deconz don't add "light" device.

If I short press (1 second) nothing happen, if I "long" press (5/6 seconds) the led blinks and the module pairs, if I "very long" press (more then 10 seconds) the module is reset.

Lol, on my side I have never tried the medium press (luckily there is only one reset button :) )

So with the medium press, the device is included, the led is green, but no entry in API ?

Just by curiosity, can you make a test with "add new light" ?

Seriously I realy don't understand.

The code use only the modelid "DIN power consumption module" for detection.
It have already worked without the "special tips", but perhaps the code have changed since.

After ebaauw reaction, now I think there is too much reason for the device will not be created^^. The only way I see is using the debug mode. @rotragit if you have time, a thing you can do.

Delete the device with all entries.
Run deconz with debug enabled, take care, it can be huge, not good at all for sd card.
Re-include the device.

Hoping to find something usefull.

rotragit commented 4 years ago

The first module was paired with "add light" because I read in a previous comment to do like that. The behaviour was the same.

Ok, I'll work on it in the weekend. The debug mode act also as a sniffer?

ebaauw commented 4 years ago

The debug mode act also as a sniffer?

Sort of, but with some limitations:

It'll only show traffic to/from the coordinator, not traffic between other devices (you'd need the firmware that comes with ZShark for that);
It's limited to (I think) ZDP and APS traffic (that uses ZCL), but typically that's enough to reverse engineer how devices work;
It's limited to traffic to/from the device clusters defined in general.xml and advertised in the Simple Descriptors.

rotragit commented 4 years ago

Ok, thank you. I should have one or two cc2531 module somewhere on my desk, buy if the debug mode is enoght I don't waste time to check te firmware, setup wireshark and so on....

ebaauw commented 4 years ago

I find WireShark a lot easier than the deCONZ debug log to find out how devices work. The log is very verbose, and the messages have inconsistent formatting, making filtering almost impossible.

rotragit commented 4 years ago

Ok, I'll try to capture the traffic with wireshark :-)

Il gio 26 mar 2020, 20:37 Erik Baauw notifications@github.com ha scritto:

I find WireShark a lot easier than the deCONZ debug log to find out how devices work. The log is very verbose, and the messages have inconsistent formatting, making filtering almost impossible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2456#issuecomment-604642641, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFSG4VXCIUWZ2I3OQAISPILRJOVIRANCNFSM4KWCD23Q .

SwoopX commented 4 years ago

how it can be in deconz and not the API, there is no whitelist or blacklist for light.

@ebaauw you were faster with your reply than me. In "addLightNode, we have some whitelisting but not too much debug output out of the box. I don't think it's related to the larger switch statement for the various deviceids though we introduced a new one here, is it?

@rotragit I personally started to prefer L2 debug in combination with a sniff ;)

Smanar commented 4 years ago

I think it will be more usefull using deconz log than sniffing zigbee traffic.

The pairing work, and the device is included in deconz, so there is no "zigbee problem', the problem is only the no device creation, so for me the problem is in the API, deconz logs will be usefull to trace the way taked by the device during integration into the API and see if the procedure is stopped somewhere (by a whitelist / blacklist), probably by the same kind of problem evoked by SwoopX.

SwoopX commented 4 years ago

@Smanar True, but I do not fully agree. A traffic sniff, imho, always helps to better understand what's exactly going on in the air. However, in the case I previously described, I got all the required entries in deconz' DB bit the sensors have just not been created. I had to add half a ton of additional debug output to identify the exact location where the miss occurred.

From my perspective remarkable, the "issue" was way later than I expected. Any previous checks on manufacturer code and modelID were passed, as they were not empty but simply contained garbage. Not sure if that makes any sense here.

rotragit commented 4 years ago

OK, sorry, I had to flash the sniffer firmware on the CC2531 dongle and to setup wireshark with the network keys. Now I'm ready. I can capture the traffic and log with debug in deconz. So I can give you both :-) Now, you want I pair the F20T60A module AND "medium press" the reset button to complete the pairing, right? At this point I will not have the sensor setup. After that I apply the tips to have also the sensor. Is that right? I don't have other modules "new" so I can do only one test :-)

Smanar commented 4 years ago

On my side, I will be happy with a succeded try. Delete the sensor, and you can use the method you want, I just need the device suceesful included in deconz but not present in API. To see why in your situation the api ignore it.

And don't worry, we have time :)

SwoopX commented 4 years ago

You may want to compile the current version of the deconz rest plugin, but exchange de_web_plugin.cpp with the version found here: https://github.com/SwoopX/st_playground It significantly produces more debug output for sensor creation. While doing the tests, I'd also recommend to go with "--dbg-info=2 --dbg-error=1" ;)

rotragit commented 4 years ago

OK, I'll setup and compile on my pc tomorrow :-)

rotragit commented 4 years ago

One question: on docker I have version .75. On Ubuntu now I see stable version is .74 and beta version is .75. It's OK I go with the beta .75?

Smanar commented 4 years ago

Yep, better with last version, even I m sure it's not the case, the problem can come from a modification between the 74 an d the 75.

rotragit commented 4 years ago

Mac addr of the module is 00:04:74:00:00:a1:32:f6. Attached zip file with deconz log + wireshark pcapng. First attempt: module "out of the box", pair with Phoscon -> Sensors. Apparently in deCONZ but not in sensors table. It's row is present in devices table:

sqlite> sqlite> select * from sensors; 1|Daylight|Daylight|PHDL00|Philips|00:21:2e:ff:ff:05:03:6f-01|1.0|{"dark":true,"daylight":false,"lastupdated":"2020-03-29T18:20:19","status":210,"sunrise":"2020-03-29T05:00:32","sunset":"2020-03-29T17:38:52"}|{"configured":true,"lat":"45.545479","long":"11.535421","on":true,"sunriseoffset":30,"sunsetoffset":-30}||normal|1 sqlite>

It disappear from deCONZ (gray) at 20:32.

1attempt.zip

rotragit commented 4 years ago

Second attempt, same as above. Pressed "medium" (three times, I don't know way this way....). Finally led is green, module is paired. No sensor created, module is in devices table: sqlite> select * from sensors; 1|Daylight|Daylight|PHDL00|Philips|00:21:2e:ff:ff:05:03:6f-01|1.0|{"dark":true,"daylight":false,"lastupdated":"2020-03-29T18:39:49","status":210,"sunrise":"2020-03-29T05:00:32","sunset":"2020-03-29T17:38:52"}|{"configured":true,"lat":"45.545479","long":"11.535421","on":true,"sunriseoffset":30,"sunsetoffset":-30}||normal|1 sqlite>

2attempt.zip

rotragit commented 4 years ago

The green led stay on for a log time, I guess the same time to go gray in the first attempt. Now if I apply the tips I get the sensor. So.... a timeout problem?

SwoopX commented 4 years ago

@rotragit Did you use my file for the testing? Both logs are almost fully calm in terms of sensor discovery.

rotragit commented 4 years ago

Yes, I used your file...

rotragit commented 4 years ago

Yes, I used your file...

I've compiled with your file and copied the resulting .so file in place of the original one. Or I think I have done so....

SwoopX commented 4 years ago

Sidenote: The device has a manufacturer specific attribute 0xF000 in the basic cluster, Uint32 with value 0000005D

SwoopX commented 4 years ago

Guys, open discussion now.

To be honest, I currently don't get why the device should be exposed as a light at all. Not sure where that came from (and yes, I'm too lazy to read through all the post again ;)), but I also seem not to have taken a close enough look at what I did in terms of supporting it. The device does also not have any on/off cluster, so from a pure functionality perspective, imho it is a mains powered sensor, which is kind of rare.

~~Now, that I have taken a closer look, I'm even more astonished that sensor creation worked out at all.~~ There's indeed two occurrences which catch it. However, the reason, why the power sensor does not get initially now makes more sense to me. Although the device seems to enter fast probe mode according to deconz log, it immediately get kicked out since it is:

an FFD device and
has rxOnWhenIdle set to true and
does not seem to report any power data (at least not out of the box or before being paired to a Legrand gateway if I recall correctly)

Please note that the above goes primarily for the first attempt.

For the second attempt, I don't see any active endpoint or simple descriptor request in the PCAP, so no idea what happened there.

Maybe another, 3rd attempt with a previous device reset and updated firmware through the Legrand gateway would give additional insights. So much for my 2 cents.

ebaauw commented 4 years ago

why the device should be exposed as a light at all.

It’s not exposed as a light; it’s exposed using (also) an inaptly named /lights resource. /lights resources have always been used to expose other devices than just lights, even back when I started with the Hue API, well over five years ago: the OSRAM smart plugs and the Philips LivingWhite smart dimmer plugs (I never managed to get my hands on one).

Originally, it made sense to expose all mains-powered, router actuators using /lights resources and all battery-powered, end-device sensors using /sensors resources. Most of the REST API plugin code still makes this distinction, especially the pairing, persist/restore, and polling logic. Today, this distinction doesn’t make sense; there’s too many devices that combine capabilities typically associated with /lights resources as well as with /sensors resources. The only true solution is to drop this outdated distinction and use /devices resources, as proposed for API v2.

The first siren exposed by the REST API plugin was the Heiman Siren. It’s exposed using two resources:

I decided to expose the IAS WD cluster as a /lights resource, because it is an actuator and because of the server Groups cluster. In the then current API version, /groups resources could only contain /lights resources. Of course nowadays in the Hue API, a /groups resource can contain/sensors resources as well, but (still?) not as actuators.
I decided to expose the IAS Zone and Power Configuration clusters as a /sensors resource, in line with other IAS Zone devices.

This was indeed the first /lights resource without state.on. Later followed by Window Covering clusters (that imho should have used open, lift, and tilt instead of mutilating on, bri, and sat) and repeaters (also without on). Thermostat clusters are an interesting case: positioning the temperature setpoint as config attribute sort-a makes sense, but the (not yet implemented) valve position really feels, smells, and behaves like an actuator. The Eurotronic Spirit doesn’t expose Groups; I don’t know about any other thermostats. I can only imagine the fun discussions we’ll have exposing door locks...

Back to the Power Consumption Module (with apologies for the detour, but you did ask for an open discussion ;-). It carries a Groups and even a Scenes cluster, but I don’t see any groupable actuator clusters. Maybe the 0xFC01 cluster provides something, but the Electrical Measurement cluster should be exposed as a ZHAPower /sensors resource. The code is already there, you’d only need to whitelist the device to create the resource and to scale the reported values.

rotragit commented 4 years ago

Maybe another, 3rd attempt with a previous device reset and updated firmware through the Legrand gateway would give attitional insights.

I cannot help here, I don't own the Legrand/bTicino gateway.

I've done another test, after resetting the module and deleting the device form deconz (if I don't do that the module join the network immediately, without creation of the sensor, the light was never created btw, also for the ones that were paired with the tips). I have opened join permission in Phoscon as a sensor. As soon as the module is shown in deconz, I apply the tips without pressing the reset button. Well, the module leave the network as you can see in wireshark attached. And of course no sensor entry is in the db.

the Electrical Measurement cluster should be exposed as a ZHAPower /sensors resource.

Yes, when paired (with reset button pressing and applying the tips) the sensor created is like that. 3attempt.zip

SwoopX commented 4 years ago

@ebaauw Thanks once again for all the details. Although I (by now) know most of it, I'm always learning, especially since you to all the history around from the beginning ;) And yes, I wanted to have the open discussion!

Maybe I'm just to eager to bend deconz into the direction it should go. I know, times were different those days but I guess we need to try to catch up a bit. And we must reduce complexity significantly (and where feasible) for further optimization and interoperability. But enough of that in this context as there's quite extensive room for discussion and preference ;)

Back to the Power Consumption Module (with apologies for the detour, but you did ask for an open discussion ;-). It carries a Groups and even a Scenes cluster, but I don’t see any groupable actuator clusters. Maybe the 0xFC01 cluster provides something, but the Electrical Measurement cluster should be exposed as a ZHAPower /sensors resource. The code is already there, you’d only need to whitelist the device to create the resource and to scale the reported values.

I, personally, do not pay much attention on the device's scenes and groups cluster, at least not for the very purpose desired being power measurement and totally agree that is does not seem to have any actuator clusters. In that sense, only the ZHAPower sensor should be exposed where I concur once again. Like I said, maybe I got that with a light wrong while being too lazy to read everything again. However, the code for sensor creation is already there and working, but as to my understanding only with a device reset and manual interaction during join. I'd prefer to get rid of that manual step reading anything but if that would result in too much code bending, we leave it at that but should share the info. During my last tests, I got the impression that the modelID and manufacturer code are not forced to be read (or not always as it should). Doesn't take too long before I start to refactor light and sensor creation to fiddle around though C++/Qt is not my home turf 😁

@rotragit Does your 3rd attempt also contain the successful sensor creation later? Can have a look in the evening... Since @Smanar mentioned a connection and firmware update would be required for the sensor to be working, I took that for granted. Maybe this device is an exception?

dresden-elektronik / deconz-rest-plugin

Support request for BTicino DIN power consumption module #2456