Garbage pickup date (mijnafvalwijzer.nl) custom_component

Hi @xirixiz

Glad you managed to add the new option for ‘count_today config option’ in 4.1.5
Thats a long desired option indeed, magic to finally see it appear.

just to be sure before upgrade to the new component, let me ask how this works out. Does this option only kick in on actual pickup days? because that’s when the sensor.first_date is confusing the setup. See:

using this markdown:

type: custom:vertical-stack-in-card
cards:
  - type: markdown
#    style: |
#      ha-card {
#      background: url("/local/mijnafvalwijzer/saver_logo.png");
#      }

    content: >
      # <font color = {{states('sensor.trash_color')}}>Afvalwijzer</font>

      <ha-icon icon= {{'mdi:delete-alert' if states('sensor.trash_firstdate') == 'vandaag' else 'mdi:delete-outline'}}> </ha-icon> Vandaag, {{states('sensor.vandaag')}}: <font color= {{states('sensor.trash_color')}}>**{{states('sensor.trash_today')}}</font>**

      <ha-icon icon= {{states('sensor.trash_next_icon')}}> </ha-icon> Volgende afval-ophaal over **<font color={{states('sensor.trash_next_color')}}>{{states('sensor.trash_next')}}</font>** {{'dag' if states('sensor.trash_next') == '1' else 'dagen'}} op:

      <ha-icon icon= 'mdi:delete-alert'> </ha-icon> {{states('sensor.trash_firstdate')|capitalize}}: **<font color={{states('sensor.trash_next_color')}}>{{states('sensor.trash_firstwastetype')}}</font>**

On non-pickup days, the first_date is always correct. So, I am not sure how to configure this, and am a bit afraid if I set it to tomorrows date it will stop functioning as desired on non pickup days…

let me rephrase:
on pickup day, first_date should be not todays trash but trash_next…
on non pickup days first-date should be as is.

of course, the same goes for sensor.trash_firstwastetype as you can see.
Hope this makes sense…

I’m trying to do something similar but struggling with scraping, can’t get anything to happen.
This is the page I’d like to scrape from, the four date values. Where do I start?
https://www.braintree.gov.uk/info/200198/recycling_information_and_advice/1158/route_4_collection_dates

this works, of course depending on the state you give your formatted sensors:


  - type: glance
    entities:
     - entity: sensor.gft_formatted
       name: GFT
     - entity: sensor.papier_formatted
       name: Papier
     - entity: sensor.plastic_verpakkingsafval_formatted
       name: Plastic
     - entity: sensor.restafval_formatted
       name: Restafval

  - type: divider

  - type: 'custom:auto-entities'
    card:
      type: glance
    filter:
      include:
        - entity_id: sensor.*_formatted
    sort:
      method: state

Top my current glance, below the auto-entities sorting glance.

first sorts on the alphabetical ‘Thu’, and following that sorts the number…

changing

      gft_formatted:
        friendly_name: 'Gft'
        value_template: >
          {{ as_timestamp(strptime(states('sensor.trash_gft'), '%d-%m-%Y')) | timestamp_custom('%a %d %b') }}

to

      gft_formatted:
        friendly_name: 'Gft'
        value_template: >
{{ as_timestamp(strptime(states('sensor.trash_gft'), '%d-%m-%Y')) | timestamp_custom('%d %b - %a') }}

would probably solve this. restarting now to test :wink:

Check:

Of course, this will run into issues when the dates cross the month. Only one solution for that: using the raw timestamps.

      restafval_trash_timestamp:
        friendly_name: 'Restafval'
        value_template: >
          {{ as_timestamp(strptime(states('sensor.trash_restafval'), '%d-%m-%Y'))}}

      plastic_verpakkingsafval_trash_timestamp:
        friendly_name: 'Plastic'
        value_template: >
          {{ as_timestamp(strptime(states('sensor.trash_plastic_verpakkingsafval'), '%d-%m-%Y'))}}

      gft_trash_timestamp:
        friendly_name: 'Gft'
        value_template: >
          {{ as_timestamp(strptime(states('sensor.trash_gft'), '%d-%m-%Y'))}}

      papier_trash_timestamp:
        friendly_name: 'Papier'
        value_template: >
          {{ as_timestamp(strptime(states('sensor.trash_papier'), '%d-%m-%Y'))}}

can probably be used in a auto_entities card sorted by state, and hopefully displaying the frontend name using the template-entity-row card.

something like this:

  - type: 'custom:auto-entities'
    card:
      type: glance
    filter:
      include:
        - entity_id: sensor.*_trash_timestamp
      options:
        type: custom:template-entity-row
        state: >
          {{ states(config.entity) | timestamp_custom('%a %d %b')}}
    sort:
      method: state

must experiment further…

Hi Samuel, the problem is that the page is parsed without dates using the hass scraper (or any other scraper). When you look at the page, it looks like:

However, when the page is scraped and parsed (https://try.jsoup.org/), it looks like this f.e. (only the waste type, without date):

<p id="greybin"></p></div>

Normally this should work in hass, but in this case the sensor stays empty, because the scraper receives no data:

  - platform: scrape
    name: Greybin
    resource: "https://www.braintree.gov.uk/info/200198/recycling_information_and_advice/1158/route_4_collection_dates"
    select: 'p[id="greybin"]'

However, this has something todo with a script not being parsed by the scraper. The dates are there, maybe you can do something with that:

<script>
//Set the date as today
    var x = new Date();

//
//
//
//PLEASE NOTE: All dates must be entered in date order. 
//PLEASE NOTE: Dates must follow the format yyyy, m, d, 23.
//PLEASE NOTE: Dates start counting from 0. January = 0, February = 1 --> December = 11.
//PLEASE NOTE: Dates must end in ", 23" in order to display if the collection is same day.
//Set Grey Bin Collection Dates
    var greybin = [new Date(2019,9,10,23),
new Date(2019,9,24,23),
new Date(2019,10,7,23),
new Date(2019,10,21,23),
new Date(2019,11,5,23),
new Date(2019,11,19,23),
new Date(2020,0,3,23),
new Date(2020,0,16,23),
new Date(2020,0,30,23),
new Date(2020,1,13,23),
new Date(2020,1,27,23),
new Date(2020,2,12,23),
new Date(2020,2,26,23),
new Date(2020,3,9,23),
new Date(2020,3,23,23),
new Date(2020,4,7,23),
new Date(2020,4,21,23),
new Date(2020,5,4,23),
new Date(2020,5,18,23),
new Date(2020,6,2,23),
new Date(2020,6,16,23),
new Date(2020,6,30,23),
new Date(2020,7,13,23),
new Date(2020,7,27,23),
new Date(2020,8,10,23),
new Date(2020,8,24,23),

];
//Set Green Bin Collection Dates
    var greenbin = [new Date(2019,9,3,23),
new Date(2019,9,17,23),
new Date(2019,9,30,23),
new Date(2019,10,14,23),
new Date(2019,10,28,23),
new Date(2020,2,5,23),
new Date(2020,2,19,23),
new Date(2020,3,2,23),
new Date(2020,3,17,23),
new Date(2020,3,30,23),
new Date(2020,4,14,23),
new Date(2020,4,29,23),
new Date(2020,5,11,23),
new Date(2020,5,25,23),
new Date(2020,6,9,23),
new Date(2020,6,23,23),
new Date(2020,7,6,23),
new Date(2020,7,20,23),
new Date(2020,8,4,23),
new Date(2020,8,17,23),

];
//Set Clear Sack Collection Dates
    var clearsack = [new Date(2019,9,3,23),
new Date(2019,9,17,23),
new Date(2019,9,30,23),
new Date(2019,10,14,23),
new Date(2019,10,28,23),
new Date(2019,11,12,23),
new Date(2019,11,27,23),
new Date(2020,0,9,23),
new Date(2020,0,23,23),
new Date(2020,1,6,23),
new Date(2020,1,20,23),
new Date(2020,2,5,23),
new Date(2020,2,19,23),
new Date(2020,3,2,23),
new Date(2020,3,17,23),
new Date(2020,3,30,23),
new Date(2020,4,14,23),
new Date(2020,4,29,23),
new Date(2020,5,11,23),
new Date(2020,5,25,23),
new Date(2020,6,9,23),
new Date(2020,6,23,23),
new Date(2020,7,6,23),
new Date(2020,7,20,23),
new Date(2020,8,4,23),
new Date(2020,8,17,23),

];
//Set Food Bin Collection Dates
    var foodbin = [new Date(2019,9,3,23),
new Date(2019,9,10,23),
new Date(2019,9,17,23),
new Date(2019,9,24,23),
new Date(2019,9,30,23),
new Date(2019,10,7,23),
new Date(2019,10,14,23),
new Date(2019,10,21,23),
new Date(2019,10,28,23),
new Date(2019,11,5,23),
new Date(2019,11,12,23),
new Date(2019,11,19,23),
new Date(2019,11,27,23),
new Date(2020,0,3,23),
new Date(2020,0,9,23),
new Date(2020,0,16,23),
new Date(2020,0,23,23),
new Date(2020,0,30,23),
new Date(2020,1,6,23),
new Date(2020,1,13,23),
new Date(2020,1,20,23),
new Date(2020,1,27,23),
new Date(2020,2,5,23),
new Date(2020,2,12,23),
new Date(2020,2,19,23),
new Date(2020,2,26,23),
new Date(2020,3,2,23),
new Date(2020,3,9,23),
new Date(2020,3,17,23),
new Date(2020,3,23,23),
new Date(2020,3,30,23),
new Date(2020,4,7,23),
new Date(2020,4,14,23),
new Date(2020,4,21,23),
new Date(2020,4,29,23),
new Date(2020,5,4,23),
new Date(2020,5,11,23),
new Date(2020,5,18,23),
new Date(2020,5,25,23),
new Date(2020,6,2,23),
new Date(2020,6,9,23),
new Date(2020,6,16,23),
new Date(2020,6,23,23),
new Date(2020,6,30,23),
new Date(2020,7,6,23),
new Date(2020,7,13,23),
new Date(2020,7,20,23),
new Date(2020,7,27,23),
new Date(2020,8,4,23),
new Date(2020,8,10,23),
new Date(2020,8,17,23),
new Date(2020,8,24,23),

];
//
//
//


//Set variables for Grey Bin Calculation
    var i = 0;
    var greybintext = "";
//Set variables for Green Bin Calculation
    var j = 0;
    var greenbintext= "";
//Set variables for Clear Sack Calculation
    var k = 0;
    var clearsacktext ="";
//Set variables for Food Bin Calculation
    var l = 0;
    var foodbintext ="";
//Set date display options
    var dateoptions = {weekday:'long', year:'numeric', month:'long', day:'2-digit'};
    

//Grey Bin Calculation
    while (greybin[i]) {
        
        if (greybin[i]>=x){
            greybintext += greybin[i].toLocaleDateString('en-GB', dateoptions);
            break;
        }
        i++;
    }
//Green Bin Calculation
    while (greenbin[j]) {
        
        if (greenbin[j]>=x){
            greenbintext += greenbin[j].toLocaleDateString('en-GB', dateoptions);
            break;
        }
        j++;
    }
//Clear Sack Bin Calculation
while (clearsack[k]) {
        
        if (clearsack[k]>=x){
            clearsacktext += clearsack[k].toLocaleDateString('en-GB', dateoptions);
            break;
        }
        k++;
    }
//Food Bin Calculation
while (foodbin[l]) {
        
        if (foodbin[l]>=x){
            foodbintext += foodbin[l].toLocaleDateString('en-GB', dateoptions);
            break;
        }
        l++;
    }
//Print Results to ID's
    document.getElementById("greybin").innerHTML = greybintext;
    document.getElementById("greenbin").innerHTML = greenbintext;
    document.getElementById("clearsack").innerHTML = clearsacktext;
    document.getElementById("foodbin").innerHTML = foodbintext;
    
</script>

Maybe a good start, but you’ll have to look into this further yourself :smiley:. Good luck!

Thanks for your help.

on the auto ordering of the sensors, this works perfectly, based on timestamp:

  - type: 'custom:auto-entities'
    card:
      type: entities
    filter:
      include:
        - entity_id: sensor.*_trash_timestamp
          options:
            type: custom:template-entity-row
            state: >
              {{state_attr(config.entity,'date')}}
    sort:
      method: state

while the same setup with glance doesn’t work:

  - type: 'custom:auto-entities'
    card:
      type: entities
    filter:
      include:
        - entity_id: sensor.*_trash_timestamp
          options:
            type: custom:template-entity-row
            state: >
              {{state_attr(config.entity,'date')}}
    sort:
      method: state

using specially new made sensors…
timestamp for state, and attribute_template for frontend date (used in the template-entity-row):

      restafval_trash_timestamp:
        friendly_name: 'Restafval'
        value_template: >
          {{ as_timestamp(strptime(states('sensor.trash_restafval'), '%d-%m-%Y'))}}
        attribute_templates:
          date: >
            {{ as_timestamp(strptime(states('sensor.trash_restafval'), '%d-%m-%Y')) | timestamp_custom('%a %d %b') }}
        device_class: timestamp

      plastic_verpakkingsafval_trash_timestamp:
        friendly_name: 'Plastic'
        value_template: >
          {{ as_timestamp(strptime(states('sensor.trash_plastic_verpakkingsafval'), '%d-%m-%Y'))}}
        attribute_templates:
          date: >
            {{ as_timestamp(strptime(states('sensor.trash_plastic_verpakkingsafval'), '%d-%m-%Y')) | timestamp_custom('%a %d %b') }}
        device_class: timestamp

      gft_trash_timestamp:
        friendly_name: 'Gft'
        value_template: >
          {{ as_timestamp(strptime(states('sensor.trash_gft'), '%d-%m-%Y'))}}
        attribute_templates:
          date: >
            {{ as_timestamp(strptime(states('sensor.trash_gft'), '%d-%m-%Y')) | timestamp_custom('%a %d %b') }}
        device_class: timestamp

      papier_trash_timestamp:
        friendly_name: 'Papier'
        value_template: >
          {{ as_timestamp(strptime(states('sensor.trash_papier'), '%d-%m-%Y'))}}
        attribute_templates:
          date: >
            {{ as_timestamp(strptime(states('sensor.trash_papier'), '%d-%m-%Y')) | timestamp_custom('%a %d %b') }}
        device_class: timestamp

device_class can be left out probably.

Will ask Thomas if this is to be expected behavior for glance card.

I do think I understand what your saying.

When there’s no trash Today, then the first next trash is set for:

  • sensor.trash_first_next_date
  • sensor.trash_first_next_in_days
  • sensor.trash_first_next_item

For example, the first next pickup is Tomorrow, GFT, 14-02-2020 (Today’s date = 13-02-2020):

[{'key': 'gft', 'value': '14-02-2020', 'days_remaining': 1}, {'key': 'papier', 'value': '19-02-2020', 'days_remaining': 6}, {'key': 'pmd', 'value': '20-02-2020', 'days_remaining': 7}, {'key': 'restafval', 'value': '06-03-2020', 'days_rem
aining': 22}]
[{'key': 'first_next_in_days', 'value': 1}]
[{'key': 'today', 'value': 'None'}]
[{'key': 'tomorrow', 'value': 'gft'}]
[{'key': 'day_after_tomorrow', 'value': 'None'}]
[{'key': 'first_next_item', 'value': 'gft'}]
[{'key': 'first_next_date', 'value': '14-02-2020'}]
['gft', 'pmd', 'restafval', 'kerstbomen', 'papier']

Then when I hardcode the Today’s date as 14-02-2020, the result is like this. So, I think this matches what you were asking.

If there is anything for Today, then only the first_next sensors will not take Today into account. If there’s nothing to be picked up Today, the first upcoming date is used.

[{'key': 'gft', 'value': '14-02-2020', 'days_remaining': 0}, {'key': 'papier', 'value': '19-02-2020', 'days_remaining': 5}, {'key': 'pmd', 'value': '20-02-2020', 'days_remaining': 6}, {'key': 'restafval', 'value': '06-03-2020', 'days_rem
aining': 21}]
[{'key': 'first_next_in_days', 'value': 5}]
[{'key': 'today', 'value': 'gft'}]
[{'key': 'tomorrow', 'value': 'None'}]
[{'key': 'day_after_tomorrow', 'value': 'None'}]
[{'key': 'first_next_item', 'value': 'papier'}]
[{'key': 'first_next_date', 'value': '19-02-2020'}]
['gft', 'pmd', 'restafval', 'kerstbomen', 'papier']
1 Like

I think this is what I was hoping for :wink: all a bit difficult to explain, but sure, that must be it. Thanks for implementing this, makes it just that extra bit more useful. And it already was pretty nice :wink:

not having tested it, so forgive me if it is already there: do you have a timestamp sensor for all trash sensors?

Given the result I have with the ordering I posted above, I think it would be very useful if your component made these automatically, and the user wouldn’t have to create these in jinja.

Thanks for the complements, and I do think we have an understanding about the first_next* sensors :smiley:

But why do you need the timestamp, why not use the attribute I’ve added? Like this:

  - card:
      type: glance
    filter:
      include:
        - entity_id: sensor.trash_gft
        - entity_id: sensor.trash_papier
        - entity_id: sensor.trash_pmd
        - entity_id: sensor.trash_restafval
    sort:
      attribute: next_pickup_in_days
      method: attribute
      numeric: true
    type: 'custom:auto-entities'

havent tried the yet, sorry.
test doesn’t sort on the date though does it? it sorts on the count of the days till the next pickup?

sorting on dates only works reliably using timestamps. so hence my effort to realize that.

maybe superfluous when your suggestion suffices, will test for sure. Still would love to be able to do the basic arithmetic based on timestamp.

otoh, the timestamp is calculated based on the days counted…or not anymore?

yes!
just to be sure, what do I need to set for count_today: ? Is this a true/false field? or yes/no. reading this it probably is yes/no, but must admit I havent seen that in configs yet. wouldn’t it be more HA to use true/false for that field?

also.copying the config on your repo results in:

Invalid config for [sensor.afvalwijzer]: [provider] is an invalid option for [sensor.afvalwijzer]. Check: sensor.afvalwijzer->provider. (See ?, line ?). 

and

Invalid config for [sensor.afvalwijzer]: [zipcode] is an invalid option for [sensor.afvalwijzer]. Check: sensor.afvalwijzer->zipcode. (See ?, line ?). 

something amiss here?

  - platform: afvalwijzer # Required
    provider: mijnafvalwijzer # Optional - mijnafvalwijzer (default) or afvalstoffendienstkalender
    zipcode: !secret postcode # Required
    housenumber: !secret huisnummer # Required
    suffix: new # Optional
  #  count_today: vandaag meetellen # Optional - Default = no
  #  default_label: 'Geen' # Optional - Default is 'Geen'

thanks for having a look
(would the old platform be in the way of the new?, trying not to delete that just yet)

finally made it to a restart, but now see this:

2020-02-13 23:15:53 ERROR (MainThread) [custom_components.afvalwijzer.sensor] Check afvaldienst platform settings ('Expecting value: line 1 column 1 (char 0)',)

and a bit further:

2020-02-13 23:15:57 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up afvalwijzer platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 159, in _async_setup_platform
    await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
  File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
    return fut.result()
  File "/config/custom_components/afvalwijzer/sensor.py", line 61, in async_setup_platform
    afvaldienst = Afvaldienst(provider, zipcode, housenumber, suffix, count_today)
  File "/usr/local/lib/python3.7/site-packages/Afvaldienst/Afvaldienst.py", line 42, in __init__
    self._jsonData = self.__get_data_json()
  File "/usr/local/lib/python3.7/site-packages/Afvaldienst/Afvaldienst.py", line 49, in __get_data_json
    jsonResponse = requests.get(jsonUrl).json()
  File "/usr/local/lib/python3.7/site-packages/requests/models.py", line 897, in json
    return complexjson.loads(self.text, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/simplejson/__init__.py", line 525, in loads
    return _default_decoder.decode(s)
  File "/usr/local/lib/python3.7/site-packages/simplejson/decoder.py", line 370, in decode
    obj, end = self.raw_decode(s)
  File "/usr/local/lib/python3.7/site-packages/simplejson/decoder.py", line 400, in raw_decode
    return self.scan_once(s, idx=_w(s, idx).end())
simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Really odd behaviour, I think the config isn’t valid. Check mine (~ line 45):

I used yes and no with a reason, long story… I`m going to leave it like this :slight_smile: .

update: also added true/false as valid values for count_today.

This will be the last update for now for a while. I have no plans adding extra features for now.

Got it working, I mistakenly added a namespace to the suffix field…

changed config into:

  - platform: afvalwijzer # Required
    provider: mijnafvalwijzer # Optional - mijnafvalwijzer (default) or afvalstoffendienstkalender
    zipcode: !secret postcode # Required
    housenumber: !secret huisnummer # Required
#    suffix: 'new' # Optional
#    count_today: false vandaag meetellen # Optional. true or false - Default = false
#    default_label: 'Geen' # Optional - Default is 'Geen'
    entity_namespace: saver

and see most sensors being created (next to the former mijnafvalwijzer sensors, sensor.trash_etc):

note 2 things:

the new (saver) setup misses the firstwastetype and firstdate sensor, which were scraped (I think)? would be nice if they could be added, since they can be used easily in a markdown card.

secondly: you create 3 sensors with the name first_next in it. Isn’t that somewhat overstating things, why not simply call these either sensor.first_date, or sensor.next_date…(and the same for in_days and item)

thanks!

Hi Marius, thanks for the info.

  • Scraping websites is really bad practice, so I removed the function permanently.
  • I agree on the sensor naming, I always find it hard to make up names :). However, I`ll leave it like this for now.

that’s too bad, but I understand your reasoning.

would you be willing to help me strip out everything no longer needed in the former mijnafvalwijzer sensor.py, to only leave the scraper? So one can still use that if desired, and not create double sensors for all the entities now created in the new package?

maybe I can use the old:

  - platform: scrape
    resource: !secret saver_scrape_resource
    name: Saver first date
    select: '.firstDate'
    scan_interval: 3600

  - platform: scrape
    resource: !secret saver_scrape_resource
    name: Saver first waste type
    select: '.firstWasteType'
    scan_interval: 3600

again, though I would have thought the CC would be better for system performance?

getting back to this, Im testing this for the moment, which makes it just a bit more generic/less verbose

  - type: 'custom:auto-entities'
    card:
      type: glance
    filter:
      include:
        - domain: sensor
          attributes:
            next_pickup_in_days: '! none'
#    sort:
#      attribute: next_pickup_in_days
#      method: attribute
#      numeric: true

though I really don’t like the view of it yet, the ordering is alright:

I take it you also customize these sensors?

took out the domain: sensor, to minimize code even further:

  - type: 'custom:auto-entities'
    card:
      type: glance
    filter:
      include:
        - attributes:
            next_pickup_in_days: '! none'

You could try this:

1 Like

Hey xirixiz,

after updating to the new component, my system seems to be bogged a lot, and is much less responsive.

ive set an update interval in my now sensor config, but not sure if this overrides the components internal settings:

SCAN_INTERVAL = timedelta(seconds=30)
MIN_TIME_BETWEEN_UPDATES = timedelta(seconds=3600)

why is the scan_interval so high, can’t we just leave that out? Seems not to be used in the code at all?

setting this in the señsor config might be better?

  - platform: afvalwijzer # Required
    provider: mijnafvalwijzer # Optional - mijnafvalwijzer (default) or afvalstoffendienstkalender
    zipcode: !secret postcode # Required
    housenumber: !secret huisnummer # Required
#    suffix: 'new' # Optional
#    count_today: false vandaag meetellen # Optional. true or false - Default = false
#    default_label: 'Geen' # Optional - Default is 'Geen'
    entity_namespace: saver
    scan_interval: 1800

no need to scan each 30 seconds is there? might be enough to simply scan during day change…

SCAN_INTERVAL is being used and MIN_TIME_BETWEEN_UPDATES limits the amount of updates.
So what actually happens is afvalwijzer only updating once per hour. When you put debug logging on, you’ll see what is actually happening. Maybe something else is slowing down your system. I removed these values before, but due to reponsive issues I re-added those values again.

If I remove SCAN_INTERVAL, and restart HASS, then HASS will only update afvalwijzer after an hour, not sooner.

yes, I noticed that too…and even now it doesn’t always initiate at startup, will test some more to see if an error is thrown or something else is amiss.

nope, nothing happens at startup:

2020-02-18 12:13:02 DEBUG (MainThread) [custom_components.afvalwijzer.sensor] Trash type list = ['gft', 'plastic verpakkingsafval', 'restafval', 'papier', 'today', 'tomorrow', 'first_next_in_days', 'first_next_item', 'first_next_date', 'day_after_tomorrow']
2020-02-18 12:13:02 DEBUG (MainThread) [custom_components.afvalwijzer.sensor] Sensors = [<Entity trash_gft: Geen>, <Entity trash_plastic verpakkingsafval: Geen>, <Entity trash_restafval: Geen>, <Entity trash_papier: Geen>, <Entity trash_today: Geen>, <Entity trash_tomorrow: Geen>, <Entity trash_first_next_in_days: Geen>, <Entity trash_first_next_item: Geen>, <Entity trash_first_next_date: Geen>, <Entity trash_day_after_tomorrow: Geen>]

update

taking out the scan_interval: 1800 from my sensor config makes it respond immediately.

OMT: please have a look at this, it makes it clearer and easier to explain:

as you can see, the component creates 4 sensors, which I have displayed in the Glance Next pickups. Only thing is, the first one is todays pickup…

It would be wonderful if the Component would create these sensors, taking into account it should skip today. Just as it does now for the count_today option (which I have not set to use the default value false), in the understanding that’s what’s needed to have it skip today in the counting of the next days. Which works perfectly now indeed.

So, could you please have a look if this is alright?

update
@xirixiz did you have a chance to look at this please? What could I do to assist in realizing the component to skips todays pickup for the next pickup dates?