Add PHD Daylight binary_sensor #195

Mariusthvdb · 2020-02-01T22:02:12Z

As title
still to do:

see to it a prefix 'hue_' is added to the device_id (currently the binary_sensor.daylight is created with friendly_name Hue Daylight)
take care of multiple Hue Hubs, creating identical sensors. A unique (Hub) Id should be added to the device_id

binary_sensor. to do: - see to it a prefix 'hue_' is added to the device_id (currently the binary_sensor.daylight is created with friendly_name Hue Daylight) - take care of multiple Hue Hubs, creating identical sensors. A unique (Hub) Id should be added to the device_id

robmarkcole · 2020-02-02T06:42:24Z

OK I want to start adding tests for the parse_whatever functions using pytest. If you are happy to do this please go ahead and add to this PR, if not I will get the ball rolling on the motion sensors

Mariusthvdb · 2020-02-02T11:19:22Z

OK I want to start adding tests for the parse_whatever functions using pytest. If you are happy to do this please go ahead and add to this PR, if not I will get the ball rolling on the motion sensors

I'd need an example how to do this, so if you would 'get the ball rolling'...

robmarkcole · 2020-02-06T08:17:49Z

OK I've added test framework

Mariusthvdb · 2020-02-10T08:20:17Z

not really understanding what to do now..

I've got my PHD sensor running just fine, not sure we need an extra test for that? do you simply create a mockup sensor with a fake parsed state? also, eg the mockup temperature sensor shows all attributes, but the parsed temperature only has a state?

I guess I could simply c&p this, but need some feedback on the why, and the above what/how...

robmarkcole · 2020-02-10T08:28:15Z

Just require a test for parse_phd, see here. The mock data is the data actually returned by the API, I included all the data to allow any future tests not needing to change the mock data

Mariusthvdb · 2020-02-10T09:19:20Z

ok, so let me try:

this I the data returned by the API:

MOCK_PHDDaylight =
{"state":{"daylight":true,"lastupdated":"2020-02-10T07:36:00"},
 "config":{"on":true,"configured":true,"sunriseoffset":30,"sunsetoffset":-30},
"name":"Daylight","type":"Daylight","modelid":"PHDL00","manufacturername":"Philips","swversion":"1.0"}

and the parsed_phd could then be (also based on the config I made for the PHD sensor like this?:

PARSED_PHDDaylight= {
    "daylight": true,
    "on":"true,
    "configured":true,
    "sunrise_offset":30,
    "sunset_offset":-30},
    "name":"Daylight",
    "type":"Daylight",
    "modelid":"PHDL00",
    "swversion":"1.0",
    "lastupdated":"2020-02-10T07:36:00",
}

and add to the def test:

    assert bs.parse_sml(MOCK_PHDDaylight) == PARSED_PHDDaylight

hope this approaches what you need...
thanks for educating me here.

robmarkcole · 2020-02-10T09:26:37Z

Correct, but note that the returned data is already being pre-processed into a python dict, by the only effect is changing true to True (same for false). Please add this and check that tests pass (the CI will run the tests)

Mariusthvdb · 2020-02-10T09:34:35Z

ok, have it setup but I fear it will add a new PR, instead of adding to this... How can I add another file to change to this PR?

robmarkcole · 2020-02-10T09:36:19Z

Sorry I dont understand. Please add to this PR

Mariusthvdb · 2020-02-10T09:39:38Z

my bad, really sorry.. How do I add another file to change to the same (this) PR?

If I simply browse to the tests file in the repo and click edit, it creates a new PR, and doesn't add to this PR.

robmarkcole · 2020-02-10T09:43:41Z

You need to rebase. This is quite fundamental stuff to understand so please take your time and make sure you are confident you understand it all

CHG: make daylight sensor unique per bridge

coveralls · 2020-02-10T10:16:27Z

Pull Request Test Coverage Report for Build 45

3 of 20 (15.0%) changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.4%) to 14.249%

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
custom_components/huesensor/binary_sensor.py	3	20	15.0%

Files with Coverage Reduction	New Missed Lines	%
custom_components/huesensor/binary_sensor.py	1	35.71%

Totals
Change from base Build 40:	-0.4%
Covered Lines:	55
Relevant Lines:	386

💛 - Coveralls

Mariusthvdb · 2020-02-10T10:26:29Z

well, I feel somewhat inadequate here.. also, since I can't find a real tutorial on these issues, I fear I must let go, until someone could instruct me. which truly is a pity, since Ive got the pr working flawlessly on my local instance.

Ive accidentally stumbled onto the @koying pr, (thanks for that) and merged it, but there's an 'uncovered' line there, which seems perfectly fine to my eyes. check fails on it though..

so 2 issues left:

the @koying pr wont merge just yet
I need assistance in rebasing my (this) pr...

robmarkcole · 2020-02-10T10:32:07Z

I saw you created tests in a seperate PR, they should be in this one

Mariusthvdb · 2020-02-10T10:41:50Z

I saw you created tests in a seperate PR, they should be in this one

yes, I understand that... I simply don't know how to do that.
Your repo has changed meanwhile so I also should rebase, which is another quest unanswered.

I truly am trying to learn and read, unfortunately the GitHub ecosystem is less straightforward than I would have hoped.

Meanwhile, the @koying PR works as expected, adding the unique hub id to the sensor, very nice indeed, thank you very much!

robmarkcole · 2020-02-10T11:08:13Z

It is a learning curve we must all go through, but it is worth it!

codecov-io · 2020-02-10T14:39:21Z

Codecov Report

❗ No coverage uploaded for pull request base (master@c13348f). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #195   +/-   ##
=========================================
  Coverage          ?   14.24%           
=========================================
  Files             ?        3           
  Lines             ?      386           
  Branches          ?        0           
=========================================
  Hits              ?       55           
  Misses            ?      331           
  Partials          ?        0

Impacted Files	Coverage Δ
custom_components/huesensor/binary_sensor.py	`35.71% <ø> (ø)`
custom_components/huesensor/remote.py	`0% <ø> (ø)`

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c13348f...db71b57. Read the comment docs.

Mariusthvdb · 2020-02-10T14:45:30Z

that might well be the case, but since no help is available, or no one is willing to point me in the correct direction, I think this must be it.

The completely incomprehensible coverage/coveralls issue which has been newly added to this only further complicates things.

I'll resort to my locally working files, and please feel free to adopt that.

robmarkcole · 2020-02-11T05:30:42Z

custom_components/huesensor/binary_sensor.py

 }


-def parse_hue_api_response(sensors):
+def parse_hue_api_response(bridgeid, sensors):


Why are you passing bridgeid?

To build unique names for the sensor when multiple bridges are involved.
There is not "unique_id" for that sensor...

That would also apply to remotes etc then. This should be applied consistently

Not sure what you mean.
All the "actual devices" have their own unique_id, assumed to be unique across bridges:

"uniqueid": "00:17:88:01:10:4f:75:9b-0b"

Added to the above , the daylight sensor is a per hub sensor, and not a Hue.
accessory
We need the hub id because people have multiple hub setups

This sensor doesn’t have a unique id like the others because it is bound to the hub. So the hub id needs to be set

OK I do see the benefit. However I do want to find a better way to handle the multiple hue hub issue. For example, the hue hub id could be an attribute on all the sensors on that hub

well, I am using it right now

Well sure, but the question is, in the context of HA, why you're using that one rather than "sun"?

There is a bunch of additional attributes in "sun" (https://www.home-assistant.io/integrations/sun/) and it's handled specifically as far as automations are involved, ie you can specify offsets in the trigger (https://www.home-assistant.io/docs/automation/trigger/#sun-trigger) while the hue offsets can only be altered with the hue app.

The only config needed is your geographic location in HA.

tbh, since the introduction of native Hue sensors in HA, one could ask this question Why, on most of the entities this CC creates...

the answer is always: because it is better, more flexible, quicker etc etc.
In this particular case: I mimic the Hue setup in my HA config. The one sensor missing was the daylight setting in the Hub.

This will allow for further logic in HA to use in home/away schedules, and the options the App offers (Hue is expanding that at the moment, given the extra rules being created)

I am aware of what we can do in the HA ecosystem, like offsets in triggers etc, but you might also know that exactly that subject is cause for great confusion in the community.

Having a clear daylight sensor being on/off following Hue rules is very very adequate and easy to use. No more confusions which (light, day, dark, above_horizon,offset)sensor to use to mimic Hue behavior. Simply use hue_daylight.

OK my decision is that at this time there is not a strong case for inclusion - each line of code adds a burden of maintainence and possibility for bugs. @Mariusthvdb please create a feature request (citing this PR) highlighting why this is substantially different from the sun sensor. If there are several people keen then I will consider again. Thanks

consider that done: thanks for the opportunity!
#212

Mariusthvdb · 2020-02-11T08:13:06Z

About the prefix (hub id) on the daylight sensor:
you are right this could be used on the other entities also. You may remember we added it to the device_tracker some time ago, albeit I another form

        kwargs = {
            "dev_id": slugify("hue_{}".format(sensor.name)),
            "host_name": sensor.name,
            "attributes": {
                "last_updated": dt_util.as_local(dt_util.parse_datetime(last_updated)),
                "unique_id": sensor.uniqueid,
            },

that could be altered to use the hub_id also. Not necessarily necessary.... (since it already has a uniqueid,) but truly consistent.

Mariusthvdb mentioned this pull request Feb 1, 2020

need help creating daylight sensor #191

Open

Merge branch 'master' into patch-3

9662b7d

CHG: make daylight sensor unique per bridge

713e304

Mariusthvdb added 2 commits February 10, 2020 11:12

Merge pull request #1 from koying/patch-3-bridge

c13348f

CHG: make daylight sensor unique per bridge

Merge branch 'master' into patch-3

5ef794a

Mariusthvdb added 2 commits February 10, 2020 12:19

Update binary_sensor.py

8ddd44d

Update binary_sensor.py

db71b57

robmarkcole reviewed Feb 11, 2020

View reviewed changes

robmarkcole closed this Feb 11, 2020

Mariusthvdb mentioned this pull request Feb 11, 2020

Feature request: add Daylight sensor #212

Open

Mariusthvdb mentioned this pull request Mar 9, 2020

missing 1 required positional argument: 'sensors' #222

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add PHD Daylight binary_sensor #195

Add PHD Daylight binary_sensor #195

Mariusthvdb commented Feb 1, 2020 •

edited

Loading

robmarkcole commented Feb 2, 2020

Mariusthvdb commented Feb 2, 2020

robmarkcole commented Feb 6, 2020

Mariusthvdb commented Feb 10, 2020

robmarkcole commented Feb 10, 2020 •

edited

Loading

Mariusthvdb commented Feb 10, 2020 •

edited

Loading

robmarkcole commented Feb 10, 2020

Mariusthvdb commented Feb 10, 2020

robmarkcole commented Feb 10, 2020

Mariusthvdb commented Feb 10, 2020

robmarkcole commented Feb 10, 2020 •

edited

Loading

coveralls commented Feb 10, 2020 •

edited

Loading

Mariusthvdb commented Feb 10, 2020

robmarkcole commented Feb 10, 2020

Mariusthvdb commented Feb 10, 2020

robmarkcole commented Feb 10, 2020

codecov-io commented Feb 10, 2020

Mariusthvdb commented Feb 10, 2020 •

edited

Loading

robmarkcole Feb 11, 2020

koying Feb 11, 2020

robmarkcole Feb 11, 2020

koying Feb 11, 2020

Mariusthvdb Feb 11, 2020 •

edited

Loading

robmarkcole Feb 11, 2020

koying Feb 11, 2020

Mariusthvdb Feb 11, 2020

robmarkcole Feb 11, 2020

Mariusthvdb Feb 11, 2020

Mariusthvdb commented Feb 11, 2020 •

edited

Loading

Add PHD Daylight binary_sensor #195

Add PHD Daylight binary_sensor #195

Conversation

Mariusthvdb commented Feb 1, 2020 • edited Loading

robmarkcole commented Feb 2, 2020

Mariusthvdb commented Feb 2, 2020

robmarkcole commented Feb 6, 2020

Mariusthvdb commented Feb 10, 2020

robmarkcole commented Feb 10, 2020 • edited Loading

Mariusthvdb commented Feb 10, 2020 • edited Loading

robmarkcole commented Feb 10, 2020

Mariusthvdb commented Feb 10, 2020

robmarkcole commented Feb 10, 2020

Mariusthvdb commented Feb 10, 2020

robmarkcole commented Feb 10, 2020 • edited Loading

coveralls commented Feb 10, 2020 • edited Loading

Pull Request Test Coverage Report for Build 45

💛 - Coveralls

Mariusthvdb commented Feb 10, 2020

robmarkcole commented Feb 10, 2020

Mariusthvdb commented Feb 10, 2020

robmarkcole commented Feb 10, 2020

codecov-io commented Feb 10, 2020

Codecov Report

Mariusthvdb commented Feb 10, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mariusthvdb Feb 11, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mariusthvdb commented Feb 11, 2020 • edited Loading

Mariusthvdb commented Feb 1, 2020 •

edited

Loading

robmarkcole commented Feb 10, 2020 •

edited

Loading

Mariusthvdb commented Feb 10, 2020 •

edited

Loading

robmarkcole commented Feb 10, 2020 •

edited

Loading

coveralls commented Feb 10, 2020 •

edited

Loading

Mariusthvdb commented Feb 10, 2020 •

edited

Loading

Mariusthvdb Feb 11, 2020 •

edited

Loading

Mariusthvdb commented Feb 11, 2020 •

edited

Loading