Deconz-rest-plugin: daylight sensor not reachable

[ErnstEeldert]

Is the recently added daylight sensor supposed to work already? I am seeing it greyed out as unreachable in Phoscon, and this is what it looks like from a REST API perspective:

{ "28": { "config": { "configured": false, "on": true, "sunriseoffset": 30, "sunsetoffset": -30 }, "etag": "e58b9cbce8e2395ee66e4b238f2bcd41", "manufacturername": "Philips", "modelid": "PHDL00", "name": "Daylight", "state": { "daylight": null, "lastupdated": "none", "status": null }, "swversion": "1.0", "type": "Daylight" } }

Updated to latest firmware and deconz version, including extra restart to no avail.

[ebaauw]

It should have configured itself from the dresden appspot server, but apparently it hasn't. You might wanna try setting config.lat and config.long to you GPS coordinates.

[manup]

Yes the auto configuration only works if internet discovery is enabled (old WebApp settings) and the gateway can reach out to the update server.

[ErnstEeldert]

Enabling internet discovery and restarting deconz did the trick. Sensor is behaving as expected now!

[srd424]

Hmm, I'm still seeing this with version 2.05.65. config.lat/long not showing via REST API, and I don't seem to be able to set them. Internet discovery is on and I have restarted the app. Any clues?

[srd424]

Actually possibly different issue, is this "greyed out"?

If not I have a different problem - I just cannot use the sensors in a rule, as I cannot create a daylight rule:

Create button is greyed out?

[ebaauw]

config.lat/long not showing via REST API

That's considered a security feature, so malicious apps cannot read your physical location. When the sensor has been configured, it shows config.configured as true:

$ ph get /sensors/1
{
  "config": {
    "configured": true,
    "on": true,
    "sunriseoffset": 0,
    "sunsetoffset": 0
  },
  "etag": "ea3eaaabdd76dc20cc61b7280d7666f1",
  "manufacturername": "Philips",
  "modelid": "PHDL00",
  "name": "Daylight",
  "state": {
    "dark": false,
    "daylight": true,
    "lastupdated": "2019-07-14T04:29:38",
    "status": 160
  },
  "swversion": "1.0",
  "type": "Daylight",
  "uniqueid": "00:21:2e:ff:ff:01:02:56-01"
}

You can set the coordinates manually by (yes, I live in Amsterdam):

$ ph put /sensors/1/config '{
  "long": "4.9098",
  "lat": "52.3423",
  "sunriseoffset": 0,
  "sunsetoffset": 0
}'

This is different from the Hue API (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/495), which expects the long value to end with E or W and lat value with N or S. I think the deCONZ API uses negative numbers for W and S.

If you want to check the configured values, they're stored in the sensors table in the database, ~/.local/share/dresden-elektronik/deCONZ/zll.db. I use sqlitebrowser to examine (and patch) it. Make sure deCONZ has been shutdown and make a backup before patching, though.

[srd424]

Ah, OK, makes sense - thank you.

As per my second comment above, I'm thinking it's actually possibly a bug / missing feature in the JS for the new WebApp?

// currently only PIR supported
  if (controlType === 'pir' && val.length > 0 && !$parent.hasClass("has-error")) {
  $btn.removeAttr("disabled");
  $btn.on('click', createSensorControl);
  app.$createSensorControlModal.removeClass('is-flsnb');
  } else if (controlType === 'flsnb') {
  $btn.removeAttr("disabled");
  $btn.on('click', createSensorControl);
  app.$createSensorControlModal.addClass('is-flsnb');
  } else {
  $btn.attr("disabled", "disabled");
  app.$createSensorControlModal.removeClass('is-flsnb');
  }

Is there an alternative approach I can use?

[ebaauw]

I wouldn’t know; I don’t use Phoscon and it’s not open source. I’ve created all my rules myself, with advanced logic like: open the bedroom curtains 10 min after my wakeup alarm went off if it’s already light, or at sunrise when it becomes light after my wakeup alarm went off.

[srd424]

Ah, OK - I'm a bit muddled about who authors what and who works for who!

[ebaauw]

I am "just" a deCONZ user who contributes to the REST API plugin (this repository). I'm also the author of homebridge-hue, and a number of other homebridge plugins, see https://github.com/ebaauw. All my efforts here on GitHub are out of a hobby (gone wild), unrelated to my daytime job.

dresden elektronik provide the following deCONZ components:

• Zigbee radio device: RaspBee, ConBee or ConBee II. Firmware is closed source. Provides a serial protocol for applications to connect to.
• The deCONZ core app. Closed source. Connects to the device over the serial protocol. Provides a C++ API to develop (dynamically linked) plugins, like the REST API plugin. Provides the GUI (on Windows or X11), which is configured through general.xml.
• The deCONZ REST API plugin. Distributed with deCONZ, but open source (this repository). Uses C++ API to interface with deCONZ core. Provides the deCONZ REST API to web apps and plugins of home automation systems. Has a SQLite configuration database.
• Phoscon web app, distributed with deCONZ. Closed source. Uses the REST API to communicate with deCONZ.
• Old web app, distributed with deCONZ. Closed source. Uses the REST API to communicate with deCONZ.

There's many (open source) apps or plugins for home automation systems provided by others that interface with these components. Most use the REST API:

• homebridge-hue plugin for homebridge for HomeKit support.
• deCONZ component for Home Assistant.
• deCONZ binding for openHAB.
• deCONZ plugin for Domoticz.
• and many more ...

Also noteworthy is the deCONZ CLI plugin, which provides command-line interface to your ZigBee devices, using the C++ API.

[srd424]

Brilliant info - thanks for going above and beyond in providing that! It looks like Home Assistant might be good for me ..

[smulle48]

Maybe I’m just stupid, but how can I make sure the new lat and long values are stored?

I’m using postman and get status 200 when posting, but when I get the status of the sensor, there are no lat and long values in the response

[ebaauw]

That’s to protect your privacy. Through the API, you can check whether config.configured is set. If you want to check the values you’ll have to access the database directly.

[smulle48]

That’s to protect your privacy. Through the API, you can check whether config.configured is set. If you want to check the values you’ll have to access the database directly.

Ahh. That makes sense. So I can be somehow sure that the values are stored if it returns 200? I used your “template” here in the thread 😁