pnbruckner / ha-sun2

Home Assistant Sun2 Sensor
The Unlicense
224 stars 20 forks source link

Request additional timestamps #75

Closed Spartacus68 closed 1 year ago

Spartacus68 commented 1 year ago

Hello,

I wanted to ask, if it is possible to create timestamps for user defined eleveation: triggering on specific elevation is possible, but the calculation of the respective timestamp can only be done for the next cycle.

In order to visualize the upcomming times, I would like to have the timestamps for the last cycles, as you have it for dusk and dawn (yesterday, today, tomorrow)

I found no support for this feature, maybe it is possible to consider, if this can be implemented in one of the next releases.

Spartacus

pnbruckner commented 1 year ago

Yes, this is a good idea, and fairly straightforward. The hardest part is adding the schema and documentation. lol!

I've already implemented the new feature. See associated PR. Feel free to give it a try or wait until I release a beta (after I add the documentation for the new sensor option.) If you do give it a try, I'd appreciate any feedback.

Basically, add something like this to your config:

sensor:
  - platform: sun2
    monitored_conditions:
      - time_at_elevation: ELEVATION  # A float value
        direction: setting  # rising or setting, default is rising
        icon: mdi:weather-sunset-down  # Default is mdi:weather-sunny
        name: Setting at ELEVATION  # Default is "Rising/Setting at [minus] ELEVATION"
Spartacus68 commented 1 year ago

Hello Phil,

thanks for the quick reply and I would really like to test this asap. But it seems that I am too stupid to implement this. Can you please give me a hint how to download the files I need to change in HA? And how can I understand this! Does it mean I can configure different elevations in my config?

like:

sensor:

Thanks a lot, Spartacus

------ Originalnachricht ------ Von "Phil Bruckner" @.> An "pnbruckner/ha-sun2" @.> Cc "Spartacus68" @.>; "Author" @.> Datum 21.02.2023 17:29:34 Betreff Re: [pnbruckner/ha-sun2] Request additional timestamps (Issue

75)

Yes, this is a good idea, and fairly straightforward. The hardest part is adding the schema and documentation. lol!

I've already implemented the new feature. See associated PR. Feel free to give it a try or wait until I release a beta (after I add the documentation for the new sensor option.) If you do give it a try, I'd appreciate any feedback.

Basically, add something like this to your config:

sensor:

platform: sun2monitored_conditions:

time_at_elevation: ELEVATION # A float valuedirection: setting # rising or setting, default is risingicon: mdi:weather-sunset-down # Default is mdi:weather-sunnyname: Setting at ELEVATION # Default is "Rising/Setting at [minus] ELEVATION" — Reply to this email directly, view it on GitHub https://github.com/pnbruckner/ha-sun2/issues/75#issuecomment-1438771056, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5CTFHJXPMJUC4JKOMOEXILWYTUO5ANCNFSM6AAAAAAVC5IX3E. You are receiving this because you authored the thread.Message ID: @.***>

Spartacus68 commented 1 year ago

Hi,

yeh! It works! Give me some more time to test the whole functionality. I will reply asap! Thanks a lot for this great feature! Spartacus.

pnbruckner commented 1 year ago

@Spartacus68

Does it mean I can configure different elevations in my config?

Yes, you can add as many time_at_evelation sensor configurations as you like.

Spartacus68 commented 1 year ago

@pnbruckner ,

yeh! You made my day!!

Spartacus68 commented 1 year ago

Hello!

I checked the new time_at_evaluation and the timestamp of my sensor.sa_rollo works perfectly. But is it correct that no trigger event is generated when a certain evaluation/ time is reached?

I tried to trigger on it like this, but it doesn´t work:

trigger:
  - platform: template
    value_template: "{{(state_attr('sensor.sa_rollo', 'today') )}}"
pnbruckner commented 1 year ago

Well, that certainly won't work, because for a template trigger to fire the template needs to render to true, which that, of course, won't.

I think what you want is:

trigger:
  - platform: time
    at: sensor.sa_rollo
Spartacus68 commented 1 year ago

Hi @pnbruckner ,

that was my first thought too, but it didn't work.......yesterday :-). Today I tried again and it works as it should. I'm sorry to bother you with such simple things.

I have now 4 configurations in my sun2.yaml and I switch my light and my shutters via this function.. I will test it during the next weeks and if there are any issues, I will let you know. Many, many thanks for support and this great addon for HA.

Spartacus

Spartacus68 commented 1 year ago

Hi @pnbruckner ,

i am still working with that great tool and I wanted to know if there is a change to implement an addon for this feature:

   - time_at_elevation: -3.4
       direction: setting
       name: Setting at -3,4° in the evening

I wanted to calculate the exact time of the elevation at -3.4 at a specific date, where :

The point is, that I can define triggers for special dates e.g. Christmas or new year´s eve in advance. This helps to define scripts which run on that specific day.

Thanks, Spartacus

Spartacus68 commented 1 year ago

Hi, I saw you have released a new version of sun2. But the "time_at_elevation"-feature is not included and the sun2 integration crashes if I update to the new version. When do you plan to integrate the feature officially?

pnbruckner commented 1 year ago

@Spartacus68, the time_at_elevation feature is still part of a beta release. Instead of updating to 2.2.2, you should update to 2.3.0b3, which still has the time_at_elevation feature, AND has the fix that was released in 2.2.2.

the sun2 integration crashes if I update to the new version

Technically, it doesn't crash, it just won't work because your configuration is invalid for 2.2.2. Again, you should use 2.3.0b3.

When do you plan to integrate the feature officially?

Well, it is, it's just that it is currently only available by using the beta release. I'll try to find some time in the coming days to release the feature in a "full" release (i.e., 2.3.0.)

ArtjomE commented 10 months ago

Hello! very nice idea @Spartacus68 and many thanks for the implementation @pnbruckner.

Can you also provide a similar sensor for azimuth ("time_at_azumit"), which is very helpful for calculating the shadow time of the photovoltaics, for example.

Thanks, Artjom

pnbruckner commented 10 months ago

@ArtjomE, the time_at_elevation sensor was pretty easy since the astral package already has a function for that. But it does not have a time_at_azimuth function, so that would be much harder -- i.e., I'd have to do a curve search, and the azimuth curve is a bit weird. I doubt I'd spend time trying to implement that. Sorry.

Spartacus68 commented 9 months ago

Hi Phil,

sorry that I get in touch with you this way. I saw that you released version 3 of sun2. It seems like you've made serious changes to the module and I'm a bit afraid to install the update. I don't have the configuration in my configuration.yaml. The sun2.yaml
is located in the folder integrations and it is load via

packages: !include_dir_named integrations from the configuration.yaml

The sun2.yaml looks currently like this and sensotr name is e.g. (sensor.su_gartenlicht) sensor:

binary_sensor:

My sensors are installed in a lot of automations and my question is how the new sun2.yaml must look like without changing the sensor-names in my automation. Is it like this way? And is the sensor name build from the "name" again or is it build from the unique_id?

sun2:

------ Originalnachricht ------ Von "Forum" @.> An "pnbruckner/ha-sun2" @.> Datum 21.02.2023 18:02:22 Betreff Re[2]: [pnbruckner/ha-sun2] Request additional timestamps (Issue

75)

Hello Phil,

thanks for the quick reply and I would really like to test this asap. But it seems that I am too stupid to implement this. Can you please give me a hint how to download the files I need to change in HA? And how can I understand this! Does it mean I can configure different elevations in my config?

like:

sensor:

  • platform sun2

    • monitred_conditions

    • elevation

    • sun_phase

    • dawn

    • time_at_elevation: -3.4 direction: setting name: Setting at -3,4° in the evening

    • time_at_elevation: -5.2 direction: rising name: Rising at -5,2° in the morning

Thanks a lot, Spartacus

------ Originalnachricht ------ Von "Phil Bruckner" @.> An "pnbruckner/ha-sun2" @.> Cc "Spartacus68" @.>; "Author" @.> Datum 21.02.2023 17:29:34 Betreff Re: [pnbruckner/ha-sun2] Request additional timestamps (Issue

75)

Yes, this is a good idea, and fairly straightforward. The hardest part is adding the schema and documentation. lol!

I've already implemented the new feature. See associated PR. Feel free to give it a try or wait until I release a beta (after I add the documentation for the new sensor option.) If you do give it a try, I'd appreciate any feedback.

Basically, add something like this to your config:

sensor:

platform: sun2monitored_conditions:

time_at_elevation: ELEVATION # A float valuedirection: setting # rising or setting, default is risingicon: mdi:weather-sunset-down # Default is mdi:weather-sunnyname: Setting at ELEVATION # Default is "Rising/Setting at [minus] ELEVATION" — Reply to this email directly, view it on GitHub https://github.com/pnbruckner/ha-sun2/issues/75#issuecomment-1438771056, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5CTFHJXPMJUC4JKOMOEXILWYTUO5ANCNFSM6AAAAAAVC5IX3E. You are receiving this because you authored the thread.Message ID: @.***>

pnbruckner commented 9 months ago

@Spartacus68

sorry that I get in touch with you this way.

No problem. But, in the future, please open a separate issue to ask a new question.

As far as changes, yes, there are changes to the way entities are named and their IDs. There's a lot of reasons for this, so I won't go into them here. But suffice it to say, whatever they come out to be, they can always be overridden in the entity registry (i.e., via the Settings dialog for each entity.) Or, if you're comfortable with editing files in the .storage folder, you can do a lot of automatic changes.

Regarding the "non-simple" entities (i.e., the ones you can still specify in YAML), the names (& entity IDs) will be derived from the name option, not the unique_id option.

Sorry there are these changes, but they kind of had to be made, and it's why I changed the major version number, which generally means incompatible changes (aka, breaking changes.)