Philips Hue Smart Plug

[pimw1]

Is there already an existing issue for this?

• I have searched the existing issues and there is none for my device

Product name

Philips Hue Smart Plug

Manufacturer

Philips

Model identifier

LOM001

Device type to add

Switch

Node info

Endpoints and clusters

Basic

Further relevant clusters

Power Configuration

On/Off

Level Control

Color Control

NA

Thermostat

NA

Simple Metering

NA

Electrical Measurement

NA

Any other cluster of relevance/interest

[Mimiix]

What's the issue with this device? As it seems to be working?

[pimw1]

There is no DDF while there should be one (see the discord "Advice" channel and Erik's response)

[ebaauw]

This is indeed a different model from the existing DDF. What’s the Image Type in the OTA Upgrade panel? This seems to be an ancient model, or at least ancient firmware. Is it an EU plug? Did you try and upgrade it’s firmware?

[pimw1]

The image type is 0x0000. It's just a regular EU version of the plug, bought in a Dutch well known retail store around 2020 i think. I've never tried to update the firmware, since that is quite difficult to do if you don't have the Hue Bridge.

[ebaauw]

Make sure to select the node, and press Query to populate the Image Type. deCONZ is perfectly able to update the firmware, the challenge is finding out where to download the file from.

Is the selected line for the plug? In that case the. Image Type is 0x0115, which is different from the LOM007’s 0x011A.

[pimw1]

Pressing Query does not change the image type, it's like nothing is happening

[ebaauw]

You need to check the line in the table; the attributes above are only populated when a firmware file has been selected to upgrade the device.

[pimw1]

The line is selected in the table, which is indeed the plug of interest. Query does not change anything. I've no firmware file selected , is that also a requirement before the image type can be read? In other words? is this the image type of the existing firmware, or the image type of the newly-to-be-installed firmware? The gui is very confusing for me.

[ebaauw]

The table shows the existing firmware as reported by the device. The fields above show the selected file for the selected node.

Yes, it's confusing, and we changed the column headers to better fit the available space. Manufacturer Id and Vendor are the Manufacturer Code (0x100B for Hue); Image Type and Image are the Image Type (0x0115) and File Version and Version are the File Version (0x0100040A). The Hue app reports the Hardware Platform Version as 100b-115, which is made up from the Manufacturer Code and Image Type. Note that the OTAU cluster reports the Manufacturer Code and File Version, but not the Image Type (it shows the default 0xFFFF). The Manufacturer Code is also reported through the Node Descriptor.

[pimw1]

Aah ok. Based on this info, i think i should use this image (0115 -> firmware 1.93.6). I'll try that and report back.

[pimw1]

I've placed the .zigbee file in the otau folder , selected it in the gui and started the update process for the selected zigbee plug. The Progress column keeps showing "Idle". Is there any way to force this?

edit: weirdly, the image type for this firmware is displayed as 0x0121, despite the github page referencing it as 0115

[pimw1]

I just realize that the smart plug has bluetooth. I'll use the Hue app to update the firmware and report back.

[ebaauw]

It should find file version 0x01001402. My guess would be that the version in the Basic cluster will be 1.222.2.

[pimw1]

Firmware is updated to 1.122.2. I've read the node descriptor / simple descriptors and all relevant attributes. Restarted deconz, and read everything again. See below the results.

Basic

On/Off

Strangly, it is still not using DDF. Should i force it manually?

[ebaauw]

We could try and add it to the DDF for the LOM007. Despite different firmwares, the devices probably behave the same. Just to be sure, could check the clusters after the upgrade: it should now expose FC03 instead of FC02. Make sure to refresh the endpoints and simple descriptors, so the GUI reflects the new list.

[pimw1]

I've refreshed the endpoint and simple descriptors twice, restarted deconz and repeated the refresh of the endpoint and simple descriptors again. Restarted deconz again and repeated yet another time.

It still displays FC02

[pimw1]

Can i use this file

...in the Phoscon ui to try it out?

[ebaauw]

Not sure, it's part of a bigger PR.
If it doesn't work, just to edit /usr/share/deCONZ/devices/philips/lom007_smart_plug.json.

[pimw1]

Both unsuccessful

• Phoscon: can only upload .ddf, not .json
• Copied the json to (rights set 775)
  
  following error occurs when trying to open it in Deconz:
  

When opening the original json:

->

[pimw1]

I think i just solved a serious error:

The official documentation (https://github.com/deconz-community/deconz-docker) states that the docker container can be run as follows

docker run -d \
    --name=deconz \
    --restart=always \
    -p 80:80 \
    -p 443:443 \
    -v /etc/localtime:/etc/localtime:ro \
    -v /opt/deconz:/opt/deCONZ \
    --device=/dev/ttyUSB0 \
    deconzcommunity/deconz

However, /etc/localtime is not an existing path. Therefore, i went with the other option of the documentation, which is: add an environment variable for the timezone (in my case TZ=Europe/Amsterdam). Restarted deconz, and voila, the unaltered DDF is used!

Somehow, /etc/localtime:/etc/localtime:ro is seriously impacting the behaviour of Deconz

[pimw1]

...or maybe not. When reapplying the old settings (-v /etc/localtime:/etc/localtime:ro and removing the environment variable), the DDF is still there.

It is pointing to the .json i've got from you

So, somehow, while the initial load of the json fails, when restarting the docker container, it starts to pick it up.
Weird behaviour. The plug is working fine. Also my other 2 plugs (which are still with the very old firmware) are working as expected with your json file.

[pimw1]

All in all, i think the conclusion is the following:

• the new json works as expected. Thanks!
• there is an unrelated issue with loading jsons in the deconz gui, which can be bypassed by restarting the deconz docker container

[ebaauw]

Please open a new bug report issue for the second point. I don't use Docker and cannot help here.

[pimw1]

Done: #7971