1MIN sensors unavailable after ha first boot.

[russ-sentient]

Having an issue where my 1min sensors show as unavailable after a cold reboot of home assistant. Selecting Reload from the integration menu resolves the issue until next reboot when I have to do it again.

[magico13]

This is typically due to errors when calling the API due to some sort of unstableness in their cloud implementation. There's several layers of retry logic built in to try to get around it, both immediate retries and utilizing some features of Home Assistant to do delayed retries but as of right now there's not much I am able to do about it.

If you can get me the logs from after a boot where the entities are showing up as unavailable I can double check that a failed HTTP call to their API is the cause and not something else. I also have plans to try to do more dynamic discovery for entities rather than just at startup and that should hopefully let it find the missing entities again after a minute or two, as of right now if they fail during setup then they won't get rediscovered automatically without a manual reload, as you've found.

[russ-sentient]

I have since rebooted a few times and it worked fine. Next time I catch it happening again I will try to get some logs.

Thanks for a great integration! Looking forward to being energy conscious right in Home Assistant.

Sent from my iPhone

On Jan 1, 2022, at 2:31 PM, Michael Marvin @.***> wrote:

 This is typically due to errors when calling the API due to some sort of unstableness in their cloud implementation. There's several layers of retry logic built in to try to get around it, both immediate retries and utilizing some features of Home Assistant to do delayed retries but as of right now there's not much I am able to do about it.

If you can get me the logs from after a boot where the entities are showing up as unavailable I can double check that a failed HTTP call to their API is the cause and not something else. I also have plans to try to do more dynamic discovery for entities rather than just at startup and that should hopefully let it find the missing entities again after a minute or two, as of right now if they fail during setup then they won't get rediscovered automatically without a manual reload, as you've found.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[fasavard]

I do have the same probleme right now, i am at my fifth reboot and i am only able to retreive the total 1MIN of all my sensor, but all of my individual sensor have empty data for the 1MIN

[fasavard]

10 time was the charm, it finally showed up

[maddoxjny]

My one min becomes unavailable throughout the day. A reload of the integration fixes the issue. I was trying to use it to see if the electric heat was on. Unfortunately, it's too unstable to use. Thanks for your work on this it's appreciated!

[happydutch]

Since a few days, various of the 1 minute metrics are unavailable. Have created an automation that detects it and reload the integration, but there are many times it doesn't work. I do not see anything in error logs that points towards issues. If there is a recommendation how to help to debug, let me know.

[fasavard]

Do you have some code to share about your reconnect automatin @happydutch , i would happily use it aswell

[happydutch]

Hi @fasavard

Automation and sensor another yaml file(s) - depends on your setup.

automation: !include_dir_merge_list automations/ sensor: !include_dir_merge_list sensors/

automations/watchdog.yaml

- alias: Emporia Vue Watchdog
  trigger:
    - platform: state
      entity_id: binary_sensor.emporia_vue_health
      from: 'on'
      to: 'off'
      for: 00:10:00
    - platform: time_pattern
      minutes: '/10'
  condition:
    condition: state
    entity_id: binary_sensor.emporia_vue_health
    state: 'off'
  action:
    - service: rest_command.reload_emporia
      data: {}

sensors/watchdog.yaml

- platform: template
  sensors:
    emporia_vue_health:
      friendly_name: "Emporia Vue Health"
      value_template: "{{ (as_timestamp(now()) - as_timestamp(states.sensor.power_fridge_xbox_tv_14_1min.last_changed) < (states('input_number.device_health_threshold')|int)) and (states('sensor.power_fridge_xbox_tv_14_1min') != 'unavailable') }}"

You can replace the input number for a hard threshold

Add to configuration.yaml

rest_command:
  reload_emporia:
    url: !secret emporia_url
    method: POST
    headers:
      authorization: !secret rest_api_token
      content-type: 'application/json'

emporia_url: https://YOUR_IP/api/config/config_entries/entry//reload

Find the hex string (entry_id) in .storage/core.config_entries. Search for emporia_vue

You will need to create a REST API token in the UI.

You can replace it directly in configuration.yaml (replace !secret ...) if you don't use a secrets.yaml file

[Tyfosho]

I've been having this issue as well. A reload of the integration seems to fix the issue for me until the next reboot occurs.

[cybernard]

I am also having this error where the 1min sensor isn't working unless I reload the module. How do I enable logging for your module so I can help troubleshoot this annoying problem.

[jaroslawp]

For me the component initialization is incomplete when first 1min update received from Emporia API does not contain sensor data - except for total 1min .. so yes, seems the dynamic discovery you mention hereabove would fix this. (I have not seen it failing after it initialized properly)

1min sensors unavailable:

2022-05-20 22:28:16 DEBUG (MainThread) [custom_components.emporia_vue] Finished fetching sensor data in 0.402 seconds (success: True)
2022-05-20 22:28:16 INFO (MainThread) [custom_components.emporia_vue] 1min Update data: {'XXXXX-1,2,3-1MIN': {'device_gid': XXXXX, 'channel_num': '1,2,3', 'usage': 0, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa8e13988>, 'reset': None}}

1min senors OK:

2022-05-20 22:32:39 DEBUG (MainThread) [custom_components.emporia_vue] Finished fetching sensor data in 0.455 seconds (success: True)
2022-05-20 22:32:39 INFO (MainThread) [custom_components.emporia_vue] 1min Update data: {'XXXXX-1,2,3-1MIN': {'device_gid': XXXXX, 'channel_num': '1,2,3', 'usage': 0.008142645060221354, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-1-1MIN': {'device_gid': XXXXX, 'channel_num': '1', 'usage': 5.003828326861063e-05, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-2-1MIN': {'device_gid': XXXXX, 'channel_num': '2', 'usage': 1.4704087045457628e-06, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-3-1MIN': {'device_gid': XXXXX, 'channel_num': '3', 'usage': 0, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-4-1MIN': {'device_gid': XXXXX, 'channel_num': '4', 'usage': 2.9383990499708386e-06, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-5-1MIN': {'device_gid': XXXXX, 'channel_num': '5', 'usage': 0.0002662634841601054, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-6-1MIN': {'device_gid': XXXXX, 'channel_num': '6', 'usage': 0, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-7-1MIN': {'device_gid': XXXXX, 'channel_num': '7', 'usage': 0.002723061875237359, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-8-1MIN': {'device_gid': XXXXX, 'channel_num': '8', 'usage': 0.0005338158469729953, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-9-1MIN': {'device_gid': XXXXX, 'channel_num': '9', 'usage': 0, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-10-1MIN': {'device_gid': XXXXX, 'channel_num': '10', 'usage': 0.0008221659056345622, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-11-1MIN': {'device_gid': XXXXX, 'channel_num': '11', 'usage': 0.0010708634376525876, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-12-1MIN': {'device_gid': XXXXX, 'channel_num': '12', 'usage': 0.003627629568311903, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-13-1MIN': {'device_gid': XXXXX, 'channel_num': '13', 'usage': 0, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-14-1MIN': {'device_gid': XXXXX, 'channel_num': '14', 'usage': 7.84270167350769e-06, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-15-1MIN': {'device_gid': XXXXX, 'channel_num': '15', 'usage': 8.104390475485059e-05, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-16-1MIN': {'device_gid': XXXXX, 'channel_num': '16', 'usage': 0, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}, 'XXXXX-Balance-1MIN': {'device_gid': XXXXX, 'channel_num': 'Balance', 'usage': -0.0010444887551996434, 'scale': '1MIN', 'info': <pyemvue.device.VueDevice object at 0xa6cf5bc8>, 'reset': None}}

emporia_vue_fail.txt emporia_vue_ok_after_reload.txt

[jaroslawp]

Seems this became somehow more broken with Beta-0.8-pre4 - after running it for a day (still a reload was required after updating) suddenly all my 1MIN sensors became 'unavailable' (except total one showing 0 watts) and I could not restore it to working order with reloading integration/restarting hassio. Downgrading to Beta-0.8-pre3 seemed to be the only option.

[fasavard]

@happydutch never had the chance to test it out, just wanted to say thank you for all the information that was a nice answer. Im trying now