Powercalc entities based on EspHome disappear after HA restart

Some powercalc entities do not start after a restart of Home Assistant.
I know this should be fixed with issue #1410 and #1153, but for me the problem still exists
I am only seeing the issue on ESPHome devices by the way, all other devices (mainly mediaplayers from google and sonos) work just fine.

Thanks for the extra information. I also have ESPHome devices so will see if I can reproduce.
It's a hard issue to debug though and don't have much time coming days, so will probably be some time (~2-3 weeks) I can have another look.

Did you setup the sensors with the GUI or YAML?
When you use the GUI can you share diagnostics? You can click the three dots at the integration panel and "Download diagnostics"

Did a quick test by creating a virtual power sensor using the GUI for an ESPHome light entity, but my power sensors stay after restart.
Here are my diagnostics.
config_entry-powercalc-794ebcaf41a73f3c15ffaed3b3ca795c.json.txt
Important thing to check is the unique id, which is pc_lego_empire_statelightkerstboompje in my case.
Notice the pc_ prefix which has been added in the fix I created to circumvent the problem.
Maybe you have created the config entry before I had a fix in powercalc version. So it could help to delete the config entry and create a new one.

Thank you for your feedback, I did add them through GUI. Here are the diagnostics for one of my esphome devices for powercalc, i do seem to have the pc_ prefix for the unique id, so not sure if recreating the entries would help. I just discovered powercalc so the current release is the only version I've tried.
config_entry-powercalc-55dd5cf697a054dc36f9a6a2008881d6.json.txt

Your setup and diagnostics looks exactly the same as me :-(. So unfortunately provides no new clues to progress in any way.
Previously when debugging the issue it was caused by another integration providing an entity with the same unique_id, causing the powercalc entity creation to be skipped, so that's why I made the powercalc entities more "unique" by adding a prefix to the entity unique id. This happens in core HA code and I cannot add any debugging logs there, so that makes it very hard / almost impossible to debug this issue. As I am not able to reproduce myself and only happens on a handful of user installations.
I suggest to try out and create an automation to reload the powercalc sensor after HA startup. It's more of less a hack, but hey if it works, why not.
There is a service "Home Assistant Core Integration: Reload config entry" which you might utilize.

When this works we can add this to the FAQ / Note in the docs as a solution for users running into this problem.

This workaround does not work

This does not work

@sweetpants You did try with the entry_id as suggested in #1484? Not entity_id.
Any errors in the logs when calling the service like this?
What happens when you call the service manually after startup (in developer tools)?

My Bad
Using below Yaml seems to work after a HA restar
alias: Restart PowerCalc integration
description: ""
trigger:

platform: homeassistant
event: start
condition: []
action:
service: homeassistant.reload_config_entry
data:
entry_id: cb273c0e1d8d36244c434a37215ab501
service: homeassistant.reload_config_entry
data:
entry_id: 960bcde19c4957bdd2cefd5f9b5bc498
mode: single

Thank you soo much, most of the time one forgets to reload the integration after a restart.
ReGards, Harry (case closed for now)

OOps, too soon. Just after a restart of HA all seems well, but after a while they disappear again and have to reload the integration again

@sweetpants That's a pitty.
I don't know how to resolve as I don't know the root cause and I cannot reproduce in any way (tried multiple times in the past).
It's really a blackbox for me why this is happening for you.
You say after a while they disappear, do you recognize any patterns in that?

I have the same issue, also with ESPHome based entities, and I cannot draw a line on when it exactly happens

Tried to create some more virtual power sensors for my ESP home devices on HA test instance. After rebooting multiple times and leaving on it's still working fine. Upgraded to latest HA version as well 2023.3.3. Will check again later today if they still work.
Some questions which can maybe help to get some progress on this issue.
Do you guys experience the issue on all ESPHome entities you have setup powercalc for, or only a few of them?
Do they get unavailable all at the same time or randomly?
Did you install any other custom components (HACS) besides powercalc. If so, which one?

Hi @bramstroker, I have the same issue.
Do you guys experience the issue on all ESPHome entities you have setup powercalc for, or only a few of them?
Problematic entities are only from ESP Home sensors - all, in my case (binary sensors).
Do they get unavailable all at the same time or randomly?
After restart hassio, integrations for esp home sensors not loaded. If I saw this issue at the first time, after reload integration entity was loaded, but missed "device_class" and "unit_of_measurement". After next restart entity missing again, but after reload integration attributes exists.
Did you install any other custom components (HACS) besides powercalc. If so, which one?
I have the same components for last year :D, but next week I update Node-Red Companion, but i thing that it is not related.
Thanks for looking into it, good luck

@Martidjen To who you are referring to "your installation"?
I'm also using Home Assistant OS for that matter. And unable to reproduce yet. Have 3 powercalc sensors for ESPHome devices setup now and did restart multiple times for a few days and keep waiting until they disappear or become unavailable somehow but they are still available. I have looked into ESPHome code and one suspicious place I have put in some extra debug logging.
Hopefully I will also hit this bug in the next days and that gives some insights.

@bramstroker Sorry, I was referring to you indeed. I was looking at the diagnostics file you shared a couple of posts back again. You may forget my previous comment then

I believe I have the same issue whereby powercalc entities for ESPHome devices are missing after restart. From what I can tell though, the entities are initially re-created before being removed shortly thereafter. If I comment out setting the device_id attribute in create_individual_sensors then this resolves the issue for me (although isn't ideal as it's much nicer to have the entities tied to the device).
This was a blind stab in the dark and I have little to no understanding of how the device and entity management works internally in HA but perhaps this is helpful in finding the root cause and sorting out a proper fix.

@trvrnrth That's definitely some good information to know, great find! However not sure where to start searching for the root cause. I have digged through the EspHome code and searched for device_id there but I cannot see any obvious yet.
When you say being removed, could you also check in config/.storage/core.entity_registry if the powercalc entities have been removed there?
I have tried to reproduce another time on both my development instance (running HA core) and another test instance running HA OS, restarting multiple times but I cannot reproduce.
I think you guys might have some other behaviour on EspHome than me (maybe some connection issues or other timing between different component loading) triggering this issue.
Might be an idea to up the logging for EspHome to see if any warning or debug messages appear on your systems.
logger:
  default: error
  logs:
    custom_components.powercalc: debug
    homeassistant.components.esphome: debug

@bramstroker I can confirm that the entities are missing from config/.storage/core.entity_registry until a reload.
There doesn't appear to be anything obviously relevant in the debug logs but I guess it could be related to the ESPHome discovery/connection etc.
I wonder if anything can be learnt from the way the switch_as_x integration handles the device binding as I've not had any issues with that and ESPHome devices?

@bramstroker I should perhaps mention that async_added_to_hass is called and the binding is done to the expected device id (which remains constant across reboots etc.).

@bramstroker I seem to be having this issue also, but not with ESPHome devices, it seems to be with manually created entries. No home assistant entities exist for them after a restart, but after clicking on reload entity, they appear.  Will try an automation to reload, but I'd love to know the cause.

@garmcqui , I have tried the automation reload config_id, but that does not work. In the log i see:
2023-03-30 11:29:43.221 ERROR (MainThread) [homeassistant.components.automation.restart_powercalc_integration] Restart PowerCalc integration (workaround): Error executing script. Error for call_service at pos 1:
2023-03-30 11:29:43.236 ERROR (MainThread) [homeassistant.components.automation.restart_powercalc_integration] Error while executing automation automation.restart_powercalc_integration:

Chiming in with another case of powercalc entities not being created on startup for an ESPHome-based binary sensor. This is reliable fixed by reloading the powercalc integration after startup.
My theory: there's a race condition. the ESPHome sensor takes a bit longer to become available and report state, and in the meantime powercalc attempts to load its state and create the power sensors from it. The source entity is unavailable, so powercalc doesn't create the sensors. Reloading the integration solves it because by the time it's reloaded, the ESPHome entity is available again.
Does this seem plausible to others who have the issue?

@bramstroker I should perhaps mention that async_added_to_hass is called and the binding is done to the expected device id (which remains constant across reboots etc.).

You mean this one right? https://github.com/bramstroker/homeassistant-powercalc/blob/master/custom_components/powercalc/sensors/abstract.py#L28. That's the main routine to get the entity bound to the correct device.
I don't know for sure why I had that other part with setting device_id attribute in place exactly. https://github.com/bramstroker/homeassistant-powercalc/blob/master/custom_components/powercalc/sensor.py#L570
But if I understand correctly you say by removing that it's working every time for the EspHome entities after a restart consistently?

@bramstroker I seem to be having this issue also, but not with ESPHome devices, it seems to be with manually created entries. No home assistant entities exist for them after a restart, but after clicking on reload entity, they appear. Will try an automation to reload, but I'd love to know the cause.

You mean creating a powercalc sensor yourself with the GUI without using autodiscovery? For the setup of powercalc entities this makes no difference. The most important thing related to this bug is the source entity you choose.
What is it in your case, and which integration provides that entity.

@bramstroker I should perhaps mention that async_added_to_hass is called and the binding is done to the expected device id (which remains constant across reboots etc.).

You mean this one right? https://github.com/bramstroker/homeassistant-powercalc/blob/master/custom_components/powercalc/sensors/abstract.py#L28. That's the main routine to get the entity bound to the correct device. I don't know for sure why I had that other part with setting device_id attribute in place exactly. https://github.com/bramstroker/homeassistant-powercalc/blob/master/custom_components/powercalc/sensor.py#L570 But if I understand correctly you say by removing that it's working every time for the EspHome entities after a restart consistently?

Yes, that's correct. After removing the set of the device_id attribute I've had no issues although of course I lose the relationship to the device. As that is what is referenced later in async_added_to_hass that callback no longer does anything.
I did also notice that switch_as_x appears to set the device only on initial init. It also sets device_info which I believe can also be used for later lookups but I'm not sure exactly what role both play there. I do use it with ESPHome entities though so it does work.
As an aside, I also have a powercalc entries which sources from a template binary sensor which has no device. This triggers the error handling when attempting to set the device id. This of course doesn't actually cause any problems but is a bit misleading. I haven't checked the state of device_entry for that scenario.
I've been meaning to set up debugpy and have a proper poke around but haven't had the time yet.

@trvrnrth Thanks for also having a look into this and trying to debug.
I might have a solution but am not able to verify this.
Do you have discord, then we may discus this further and I can send you new source code to try out?
bramski#3414

I noticed the same behaviour with my custom added esphome led controllers. If needed I can also do some testing

I am also experiencing issues with the entities disappearing on HA startup, but, also for other reasons (details below). Hopefully I can provide some further information that may help track this down. Powercalc was installed yesterday from HACS so hopefully this is the latest version. HA is up to date details below:
Home Assistant 2023.3.6
Supervisor 2023.03.3
Operating System 9.5
Frontend 20230309.1 - latest
I have 15 powercalc power/energy integrations defined. These are a mix of autodiscovered, groups, manual (library) and manual (fixed).
I have found the issue to be simply reproduced by modifying the device the sensors are linked to. In my case this is changing the 'area' for the device.
Using Settings->Devices & Services->Devices select the affected device. Edit the device name and modify the area for the device. Select 'update' and the sensors are gone. The sensors can be restored using the homeassistant.reload_config_entry service in developer tools and referencing the previously recorded 'entry_id'.

Perhaps this will provide further information. Note: Powercalc version is 1.4.1
The following table lists all of my powercalc sensors. Columns are 'Source Sensor', 'Source Sensor State', Power Sensor State', 'Energy Sensor State'.
Note the following device type for the sensors that 'disappear'.
                             Sensor light.hallway_light                      Arlec  GLD130P3HA (9sj5h3uusahw59je)

by Tuya (note the light is using the Tuya integration not Arlec)
Sensor light.laundry_light                      Arlec  GLD130P3HA (9sj5h3uusahw59je)
by Tuya (note the light is using the Tuya integration not Arlec)
Sensor light.spare_bedroom_spot         Arlec  GLD130P3HA (9sj5h3uusahw59je)
by Tuya (note the light is using the Tuya integration not Arlec)
Sensor light.master_bedroom_light      ESPHome
Sensor light.front_door_light                ESPHome
Sensor light.decklights                         ESPHome
Sensor light.salt_lamp                          Belkin WEMO switch
Sensor light.kitchen_light                     Belkin WEMO switch
Sensor light.main_kitchen                    ESPHome
All of the device types that do not disappear are Google Mini's and Philips Hue
Modifying the 'Area' of the parent device causing the power and energy sensors to 'disappear' for any device in the list. So I think this is a related but different issue.

Relevant extract from core.config_entries
  {
    "entry_id": "7084c49423ea2f4ff6c905f4c90738da",
    "version": 2,
    "domain": "powercalc",
    "title": "Lower Bathroom Speaker",
    "data": {
      "entity_id": "media_player.googlehome8812",
      "manufacturer": "google",
      "model": "Home Mini (HOA)",
      "unique_id": "pc_d67fe854-1aea-8a23-dfda-8df4d4db5f31",
      "sensor_type": "virtual_power",
      "name": "Lower Bathroom Speaker"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_d67fe854-1aea-8a23-dfda-8df4d4db5f31",
    "disabled_by": null
  },
  {
    "entry_id": "868b431737483a4e5eb82c53b11cc69d",
    "version": 2,
    "domain": "powercalc",
    "title": "Main Bathroom Speaker",
    "data": {
      "entity_id": "media_player.main_bathroom_speaker",
      "manufacturer": "google",
      "model": "Nest Mini (H2C)",
      "unique_id": "pc_e038fc8c-9bd5-00e6-221a-1b4ec8b1ae33",
      "sensor_type": "virtual_power",
      "name": "main_bathroom_speaker"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_e038fc8c-9bd5-00e6-221a-1b4ec8b1ae33",
    "disabled_by": null
  },
  {
    "entry_id": "e3c163c07297f8654dacfdbaa724a6f6",
    "version": 2,
    "domain": "powercalc",
    "title": "Master Bedroom Speaker",
    "data": {
      "entity_id": "media_player.master_bedroom_speaker",
      "manufacturer": "google",
      "model": "Home Mini (HOA)",
      "unique_id": "pc_9623285e-95bd-d494-c084-69316c1c2134",
      "sensor_type": "virtual_power",
      "name": "Master Bedroom Speaker"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_9623285e-95bd-d494-c084-69316c1c2134",
    "disabled_by": null
  },
  {
    "entry_id": "3520fbdbeb70ab743da8185e6c61688a",
    "version": 2,
    "domain": "powercalc",
    "title": "Julies Light",
    "data": {
      "entity_id": "light.julies_light",
      "manufacturer": "signify",
      "model": "LTW010",
      "unique_id": "pc_0x0017880102e66e81_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Julies Light"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x0017880102e66e81_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "d5308cc8d6144b8174d62b60bfa409aa",
    "version": 2,
    "domain": "powercalc",
    "title": "Steves Light",
    "data": {
      "entity_id": "light.steves_light",
      "manufacturer": "signify",
      "model": "LWB010",
      "unique_id": "pc_0x0017880103560900_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Steves Light"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x0017880103560900_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "6c4d4fbb56d8b7470c4ad7aae264dc8f",
    "version": 2,
    "domain": "powercalc",
    "title": "Guest Bedroom Light",
    "data": {
      "entity_id": "light.guest_bedroom_light",
      "manufacturer": "signify",
      "model": "LWB010",
      "unique_id": "pc_0x001788010287d1ca_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Guest Bedroom Light"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x001788010287d1ca_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "2ec59992fb154e3adae0d7d846fa411f",
    "version": 2,
    "domain": "powercalc",
    "title": "Spare Bedroom Light",
    "data": {
      "entity_id": "light.spare_bedroom_light",
      "manufacturer": "signify",
      "model": "LWB010",
      "unique_id": "pc_0x0017880103560b42_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Spare Bedroom Light"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x0017880103560b42_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "0a57ad37eb63918bca759dd803756cad",
    "version": 2,
    "domain": "powercalc",
    "title": "Lounge Lamp",
    "data": {
      "entity_id": "light.lounge_lamp",
      "manufacturer": "signify",
      "model": "LWB010",
      "unique_id": "pc_0x0017880103560afa_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Lounge Lamp"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x0017880103560afa_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "6ac0e9830f9042e34e701f0e1e1d529f",
    "version": 2,
    "domain": "powercalc",
    "title": "Back Door Light",
    "data": {
      "entity_id": "light.back_door_light",
      "manufacturer": "signify",
      "model": "LWB010",
      "unique_id": "pc_0x00178801035608fa_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Back Door Light"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x00178801035608fa_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "ce8e8c1a8bdef7d02d7c6f46e9bce2f4",
    "version": 2,
    "domain": "powercalc",
    "title": "Family Room Light 1",
    "data": {
      "entity_id": "light.family_room_light_1",
      "manufacturer": "signify",
      "model": "LCT003",
      "unique_id": "pc_0x00178801035ae3f2_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Family Room Light 1"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x00178801035ae3f2_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "a568005d178493d05d0a5d50f8de0dba",
    "version": 2,
    "domain": "powercalc",
    "title": "Family Room Light 2",
    "data": {
      "entity_id": "light.family_room_light_2",
      "manufacturer": "signify",
      "model": "LCT003",
      "unique_id": "pc_0x00178801036d1f35_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Family Room Light 2"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x00178801036d1f35_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "49ce2212f9f0d4e0b0f05359a4c4ddd0",
    "version": 2,
    "domain": "powercalc",
    "title": "Family Room Light 3",
    "data": {
      "entity_id": "light.family_room_light_3",
      "manufacturer": "signify",
      "model": "LCT003",
      "unique_id": "pc_0x00178801036d1cc4_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Family Room Light 3"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x00178801036d1cc4_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "faa0fdc234fa02c4038ce451ec6515f1",
    "version": 2,
    "domain": "powercalc",
    "title": "Family Room Light 4",
    "data": {
      "entity_id": "light.family_room_light_4",
      "manufacturer": "signify",
      "model": "LCT003",
      "unique_id": "pc_0x00178801025e56f0_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Family Room Light 4"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x00178801025e56f0_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "b48cdcd94cb954e1ebcfa397f4087a58",
    "version": 2,
    "domain": "powercalc",
    "title": "Family Room Light 5",
    "data": {
      "entity_id": "light.family_room_light_5",
      "manufacturer": "signify",
      "model": "LCT003",
      "unique_id": "pc_0x00178801035afb3a_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Family Room Light 5"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x00178801035afb3a_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "3511e3e8da8bfb965e2da64f954a5dea",
    "version": 2,
    "domain": "powercalc",
    "title": "Family Room Light 6",
    "data": {
      "entity_id": "light.family_room_light_6",
      "manufacturer": "signify",
      "model": "LCT003",
      "unique_id": "pc_0x00178801025e50a7_light_zigbee2mqtt",
      "sensor_type": "virtual_power",
      "name": "Family Room Light 6"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "integration_discovery",
    "unique_id": "pc_0x00178801025e50a7_light_zigbee2mqtt",
    "disabled_by": null
  },
  {
    "entry_id": "78aa4a6a470502328b75969a74eef5de",
    "version": 2,
    "domain": "powercalc",
    "title": "Family Room Lights",
    "data": {
      "name": "Family Room Lights",
      "create_utility_meters": false,
      "hide_members": true,
      "unique_id": "family_room_lights_group",
      "group_member_sensors": [
        "ce8e8c1a8bdef7d02d7c6f46e9bce2f4",
        "a568005d178493d05d0a5d50f8de0dba",
        "49ce2212f9f0d4e0b0f05359a4c4ddd0",
        "faa0fdc234fa02c4038ce451ec6515f1",
        "b48cdcd94cb954e1ebcfa397f4087a58",
        "3511e3e8da8bfb965e2da64f954a5dea"
      ],
      "sensor_type": "group"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "family_room_lights_group",
    "disabled_by": null
  },
  {
    "entry_id": "ba29e742625cefc8503864605318cd91",
    "version": 1,
    "domain": "group",
    "title": "Family Room Lights",
    "data": {},
    "options": {
      "group_type": "light",
      "name": "Family Room Lights",
      "entities": [
        "light.family_room_light_1",
        "light.family_room_light_2",
        "light.family_room_light_3",
        "light.family_room_light_4",
        "light.family_room_light_5",
        "light.family_room_light_6"
      ],
      "hide_members": true
    },
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": null,
    "disabled_by": null
  },
  {
    "entry_id": "e7c16bd1b7798e6c8fd6448c014584db",
    "version": 2,
    "domain": "powercalc",
    "title": "Hallway Light",
    "data": {
      "entity_id": "light.hallway_light",
      "create_energy_sensor": true,
      "create_utility_meters": false,
      "manufacturer": "arlec",
      "model": "GLD130P3HA",
      "energy_integration_method": "left",
      "unique_id": "pc_tuya.bfa7cce6edbaea77f7ca0vswitch_led",
      "sensor_type": "virtual_power",
      "name": "Hallway Light"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "pc_tuya.bfa7cce6edbaea77f7ca0vswitch_led",
    "disabled_by": null
  },
  {
    "entry_id": "3ba970c57b2b1b2bdbb6d88cecbeec32",
    "version": 2,
    "domain": "powercalc",
    "title": "Laundry Light",
    "data": {
      "entity_id": "light.laundry_light",
      "create_energy_sensor": true,
      "create_utility_meters": false,
      "manufacturer": "arlec",
      "model": "GLD130P3HA",
      "energy_integration_method": "left",
      "unique_id": "pc_tuya.bff5346dddbb331714uajbswitch_led",
      "sensor_type": "virtual_power",
      "name": "Laundry Light"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "pc_tuya.bff5346dddbb331714uajbswitch_led",
    "disabled_by": null
  },
  {
    "entry_id": "f695aa69dd5bafbc16d77ce306b20a8b",
    "version": 2,
    "domain": "powercalc",
    "title": "Spare Bedroom Spot",
    "data": {
      "entity_id": "light.spare_bedroom_spot",
      "create_energy_sensor": true,
      "create_utility_meters": false,
      "manufacturer": "arlec",
      "model": "GLD130P3HA",
      "energy_integration_method": "left",
      "unique_id": "pc_tuya.bf4b4ff4d8ee78fab9iwu2switch_led",
      "sensor_type": "virtual_power",
      "name": "Spare Bedroom Spot"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "pc_tuya.bf4b4ff4d8ee78fab9iwu2switch_led",
    "disabled_by": null
  },
  {
    "entry_id": "a5f6bd4e3a095a2424be69caec9ea1a0",
    "version": 2,
    "domain": "powercalc",
    "title": "Master Bedroom Light",
    "data": {
      "entity_id": "light.master_bedroom_light",
      "mode": "fixed",
      "create_energy_sensor": true,
      "create_utility_meters": false,
      "fixed": {
        "power": 9.0
      },
      "energy_integration_method": "left",
      "unique_id": "pc_bedroomirlightmaster_bedroom_light",
      "sensor_type": "virtual_power",
      "name": "Master Bedroom Light"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "pc_bedroomirlightmaster_bedroom_light",
    "disabled_by": null
  },
  {
    "entry_id": "5fb9b88cad6f224eb89dbb3d349424e9",
    "version": 2,
    "domain": "powercalc",
    "title": "Front Door Light Power",
    "data": {
      "entity_id": "light.front_door_light",
      "mode": "fixed",
      "create_energy_sensor": true,
      "create_utility_meters": false,
      "name": "Front Door Light Power",
      "fixed": {
        "power": 9.0
      },
      "energy_integration_method": "left",
      "unique_id": "pc_frontdoorlightlightfront_door_light",
      "sensor_type": "virtual_power"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "pc_frontdoorlightlightfront_door_light",
    "disabled_by": null
  },
  {
    "entry_id": "6c6c30ab46ed1a78c637de47577c7996",
    "version": 2,
    "domain": "powercalc",
    "title": "Decklights",
    "data": {
      "entity_id": "light.decklights",
      "mode": "fixed",
      "create_energy_sensor": true,
      "create_utility_meters": false,
      "fixed": {
        "power": 54.0
      },
      "energy_integration_method": "left",
      "unique_id": "pc_deck-lightslightdecklights",
      "sensor_type": "virtual_power",
      "name": "Decklights"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "pc_deck-lightslightdecklights",
    "disabled_by": null
  },
  {
    "entry_id": "9fb45b490e0ec91bd3a2ea4cd00d61bf",
    "version": 2,
    "domain": "powercalc",
    "title": "Salt Lamp",
    "data": {
      "entity_id": "light.salt_lamp",
      "mode": "fixed",
      "create_energy_sensor": true,
      "create_utility_meters": false,
      "fixed": {
        "power": 4.0
      },
      "energy_integration_method": "left",
      "unique_id": "pc_5846164e95bd86dc539e3f952beb43a1",
      "sensor_type": "virtual_power",
      "name": "Salt Lamp"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "pc_5846164e95bd86dc539e3f952beb43a1",
    "disabled_by": null
  },
  {
    "entry_id": "ba2bde9f2d901aa47477829344eebb39",
    "version": 2,
    "domain": "powercalc",
    "title": "Kitchen Light S",
    "data": {
      "entity_id": "light.kitchen_light",
      "mode": "fixed",
      "create_energy_sensor": true,
      "create_utility_meters": false,
      "name": "Kitchen Light S",
      "fixed": {
        "power": 16.5
      },
      "energy_integration_method": "left",
      "unique_id": "pc_3b5d18bfc7ef4ca70607c573245c61b0",
      "sensor_type": "virtual_power"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "pc_3b5d18bfc7ef4ca70607c573245c61b0",
    "disabled_by": null
  },
  {
    "entry_id": "f3435b594c65f340722452b71937ab5f",
    "version": 2,
    "domain": "powercalc",
    "title": "Kitchen Light N",
    "data": {
      "entity_id": "light.main_kitchen",
      "mode": "fixed",
      "create_energy_sensor": true,
      "create_utility_meters": false,
      "name": "Kitchen Light N",
      "fixed": {
        "power": 16.5
      },
      "energy_integration_method": "left",
      "unique_id": "pc_kitchenirlightmain_kitchen",
      "sensor_type": "virtual_power"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "pc_kitchenirlightmain_kitchen",
    "disabled_by": null
  },
  {
    "entry_id": "69f6f3132888241568d6962008cf4721",
    "version": 2,
    "domain": "powercalc",
    "title": "Front Gate",
    "data": {
      "entity_id": "binary_sensor.gate_operating",
      "mode": "fixed",
      "create_energy_sensor": true,
      "create_utility_meters": false,
      "name": "Front Gate",
      "standby_power": 14.0,
      "fixed": {
        "power": 19.0
      },
      "energy_integration_method": "left",
      "unique_id": "pc_gatecontrolbinary_sensorgate_operating",
      "sensor_type": "virtual_power"
    },
    "options": {},
    "pref_disable_new_entities": false,
    "pref_disable_polling": false,
    "source": "user",
    "unique_id": "pc_gatecontrolbinary_sensorgate_operating",
    "disabled_by": null
  }

I think I have found a fix now with https://github.com/bramstroker/homeassistant-powercalc/pull/1626.
Will merge and release a new beta version shortly.

1.5.0-beta1 looks to have resolved the missing entities after restart for my ESPHome device. Thanks for taking the time to get to the bottom of the issue @bramstroker 🥳

@trvrnrth Awesome, great to hear we finally seem to have this issue resolved. Also thanks for your input. When some others reporting in this topic can also verify I will release the new stable 1.5.0 version.

I've downloaded the beta version as well and restarted home assistant a couple of times to test. The issue does seem to be fixed with this version, yay!
Funny thing, even after downgrading back to version 1.4.1 the devices keep showing up after restarts now, think the powercalc entries are still device bound after downgrading. Guess after re-adding them the issue will return, but that shouldn't be an issue anymore.
Thank you very much for your efforts

Works for me. Following a restart, all sensors remain attached to the relevant device. Modifying the area of the parent device does not affect the power or energy sensors.
Well done Bram and thanks for the timely response.

Just released 1.5.0. Thanks everyone for reporting and testing. We can finally close this issue.

Happy to report this has resolved my issue with sensors disappearing too. 👍 Thanks Bram

Thank you guys for fixing this issue. Just tested with latest version and after HA restart, all is still there with an additional device entitie. Well done


treafik 1.3.5, traefikui not found providers...

this is pod logs...
ERROR: logging before flag.Parse: E0808 11:57:09.535791      11 reflector.go:199] github.com/containous/traefik/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1beta1.Ingress: Get https://<IP_ADDRESS>:443/apis/extensions/v1beta1/ingresses?resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout
ERROR: logging before flag.Parse: E0808 11:57:09.535883      11 reflector.go:199] github.com/containous/traefik/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Secret: Get https://<IP_ADDRESS>:443/api/v1/secrets?resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout

traefik version:  v1.3.5
Docker Server:
Version:      17.07.0-ce-rc1
API version:  1.31 (minimum version 1.12)
Go version:   go1.8.3
Git commit:   8c4be39
Built:        Wed Jul 26 03:50:43 2017
OS/Arch:      linux/amd64
Experimental: false
Kubernetes: v1.7.3
//Kuberentes api config
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=<IP_ADDRESS>/16"

==================================================
//DaemonSet config
kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
  name: traefik-ingress-lb
  namespace: kube-system
  labels:
    k8s-app: traefik-ingress-lb
spec:
  template:
    metadata:
      labels:
        k8s-app: traefik-ingress-lb
        name: traefik-ingress-lb
    spec:
      terminationGracePeriodSeconds: 60
      hostNetwork: true
      restartPolicy: Always
      containers:
      - image: traefik
        name: traefik-ingress-lb
        resources:
          limits:
            cpu: 200m
            memory: 30Mi
          requests:
            cpu: 100m
            memory: 20Mi
        ports:
        - name: http
          containerPort: 80
          hostPort: 80
        - name: admin
          containerPort: 8580
        args:
        - --web
        - --web.address=:8580
        - --kubernetes

@icyblazek the issue tracker is meant for bugs and feature requests only, please create a question on StackOverflow or ask in the Slack channel. Your issue is very likely an end-user related problem (and seemingly unrelated to Traefik as the logs indicate that your pod cannot reach the Kubernetes API server at <IP_ADDRESS>:443).

@timoreimann ok, thx for your reply.


Reporters stop under load and don't start again until app restart

To replicate: run Api.InfluxDB.Sample and send ~100 concurrent request and notice reporting to influxdb stops and the reporter is no longer running.

Can't replicate, assuming this was fixed when some concurrency issues where fixed previously

Writing to Debug was causing blocking of threads

Writing to Debug was causing blocking of threads


[Feature] Add a force flag to the app release command

WHY are these changes introduced?
Fixes #3167
Implement the force flag on the app release command to bypass the interactive prompt.
WHAT is this pull request doing?
Copy the flag functionality from deploy.
How to test your changes?
shopify app release --version=123 --force should proceed without prompting.
Behavior with PR
Pipeline without --force:

Pipeline with --force:

Post-release steps

Measuring impact
How do we know this change was effective? Please choose one:

[ ] n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
[x] Existing analytics will cater for this addition
[ ] PR includes analytics changes to measure impact

Checklist

[x] I've considered possible cross-platform impacts (Mac, Linux, Windows)
[x] I've considered possible documentation changes

Requires an update to https://shopify.dev/docs/apps/tools/cli/commands#release

[ ] I've made sure that any changes to dev or deploy have been reflected in the internal flowchart.

We do a deploy --no-release --force when we build the web app and then calls release separately when the app is deployed. Our deployment system doesn't have the full source with dev dependencies to invoke deploy. This is the solution I came up with to handle coordinating the deployed version of the web app along with the app extension.
I did sign the CLA. I'm not sure why that step is failing or how to get back to the signing form.

I pulled in latest from upstream in hopes that clears up the tests. 🤞  I don't know how my change would affect those tests.


Reverse ordering of candidates and selection.

When using a buffer to show candidates the input is displayed in the mini buffer and the "best" candidate is displayed at the top.
I really like the behavior where the input is at the bottom and the candidates from best to worst extend upward. Similar to how fzf does.
Is there a hook that would enabled me to write a small bit of elisp to reverse the display? I've dug through selectrum.el a bit but didn't have anything jump out at me that might accomplish this.
cc: @minad because of the relation to #470 and because of their knowledge of selectrum.

Duplicate #525. I tried this once briefly in my Vertico package after @grolongo asked me about it. See https://github.com/minad/vertico/issues/19#issuecomment-823689341. I think it is not really a good configuration. If you reverse the candidates you also have to reverse the up/down commands and so on. It is quite intrusive.

In Selectrum you may want to adjust the function selectrum--vertical--display-style.

@milkypostman I added this in my init when I was using selectrum:
(setq-default selectrum-display-action '(display-buffer-at-bottom
                                         (window-parameters (mode-line-format . none))))

The second line is here because otherwise the mode-line would hide the last candidate in the list, and I didn't find out how to reverse the narrowing from bottom to top (like in fzf).

Oh this is great. Given the advice in Vertico I may give that another shot.
@minad thanks for the help.
@grolongo thanks for the tip. mind elaborating on "when I was using selectrum"?

@milkypostman I stopped using it for no big reason really. I was just experimenting with a few different lightweight completion systems like Selectrum, Ido, minibuffer+Embark, Icomplete-vertical and so on and just found out about Vertico which is described as even more minimalistic than Selectrum. I also wasn't using prescient as I'm only relying on orderless for sorting which is good enough for me. @minad is also behind Consult and Marginalia which I also use along Vertico so that gives a good synergy between the three and he has been really helpful in a few issues I opened accross his different projects. I also see him active in emacs-devel debating ideas for the native completion API so I'm sure he has good knowledge of the internals.
Anyway I never found any dramatic bug or performance issue in Selectrum, it's really good. If only I could have find a way to reverse the order of candidates for them to be displayed from best to worst and extend upward like you described I would have stayed with Selectrum. Now I'm just using Vertico with most of the defaults.

I actually managed to get this going pretty easily by changing the selectrum--vertical-display-style function. I think I could advise the function but then I need to take the candidate list that is returned, as a string, and split it again and then add newlines between each element and it just seemed like too much work. Well, I guess maybe it's a split then join but that seemed like more work. Maybe I'll work on that now that I understand how this function works.
And of course I had to change the C-n and C-p bindings to selectrum-previous-candidate and selectrum-next-candidate respectively.
  (defun selectrum--vertical-display-style
      (win input nrows _ncols index
	   max-index _first-index-displayed _last-index-displayed)
    "Insert candidates vertically into current buffer.
Used as insertion function for `vertical' display style, see
`selectrum-display-style'. WIN is the window where buffer will get
displayed in. INPUT is the input string used to highlight the
candidates. NROWS is the number of lines available and NCOLS the
number of available columns. If there are candidates INDEX is the
index of the currently selected candidate and MAX-INDEX is the index
of the maximal index of the collection. When candidates are already
displayed FIRST-INDEX-DISPLAYED is the index of the candidate that is
displayed first and LAST-INDEX-DISPLAYED the index of the last one."
    (let* ((first-index-displayed
	    (if (not index)
		0
	      (selectrum--clamp
	       ;; Adding one here makes it look slightly better, as
	       ;; there are guaranteed to be more candidates shown
	       ;; below the selection than above.
	       (1+ (- index (max 1 (/ nrows 2))))
	       0
	       (max (- (1+ max-index) nrows)
		    0))))
	   (i first-index-displayed)
	   (highlighted-candidates
	    (selectrum--highlighted-candidates
	     input
	     first-index-displayed nrows))
	   (fill-rows (max 0 (- nrows (length highlighted-candidates))))
	   (metadata (selectrum--metadata))
	   (annotf (or (completion-metadata-get metadata 'annotation-function)
		       (plist-get completion-extra-properties
				  :annotation-function)))
	   (aff (or (completion-metadata-get metadata 'affixation-function)
		    (plist-get completion-extra-properties
			       :affixation-function)))
	   (docsigf (plist-get completion-extra-properties :company-docsig))
	   (groupf (and selectrum-group-format
			(completion-metadata-get metadata 'group-function)))
	   (candidates (cond (aff
			      (selectrum--affixate aff highlighted-candidates))
			     ((or annotf docsigf)
			      (selectrum--annotate
			       highlighted-candidates annotf docsigf))
			     (t highlighted-candidates)))
	   (last-title nil)
	   (lines nil))
      (dolist (cand candidates)
	(when-let (new-title (and groupf (funcall groupf cand nil)))
	  (unless (equal last-title new-title)
	    (push (format selectrum-group-format (setq last-title new-title)) lines)
	    (push "\n" lines))
	  (setq cand (funcall groupf cand 'transform)))
	(let* ((formatting-current-candidate
		(eq i index))
	       (newline
		(if (and formatting-current-candidate
			 (if (eq selectrum-extend-current-candidate-highlight
				 'auto)
			     (or aff annotf docsigf)
			   selectrum-extend-current-candidate-highlight))
		    (selectrum--selection-highlight "\n")
		  "\n"))
	       (full-cand (selectrum--format-candidate
			   input cand i index
			   first-index-displayed
			   'should-annotate)))
	  (push newline lines)  ; *** swapped with the row below
	  (push full-cand lines)
	  (cl-incf i)))
      (list
       (length highlighted-candidates)
       first-index-displayed
       (if highlighted-candidates
	   (apply #'concat
		  (append (make-list fill-rows "\n") lines)) ; *** changed to add fill lines
	 ""))))

@milkypostman this is great! thanks a lot for sharing. Do you consider to propose this to have it merge in Selectrum?
@minad what do you think?

honestly, I like the idea of vertico but it has some bugs for me. Given @minad 's contributions with marginalia and consult I may try to more actively work with vertico and improve that.
I think the integration with selectrum is up to @raxod502 but they are busy right now which I understand.

@milkypostman

honestly, I like the idea of vertico but it has some bugs for me.

Which kind of bugs? I would appreciate if you report them. There are no serious open issues on the Vertico tracker. However Vertico is young and hasn't got as much exposure as Selectrum.

@minad I had an issue where when I typed ~/ it wouldn't actually show the directories. I tried it right now and everything worked well but it was a couple weeks ago. at the time I didn't have the spare minutes to try and repro solidly so I just switched back and figured I'd try again later. Since this is the selectrum issue tracker I say we take this conversation elsewhere.
If I encounter it again I'll try then.

@clemera is whom you probably want to be talking to these days as he's done all the substantial work on Selectrum in the last many months, not me. That said, I'd personally support the addition of a user option that would allow easily reversing the order of the candidate display.


output newline at end if not on a terminal

When user redirects podman images, we do not output new lines
between data, so we want to make sure we print a new line at the
end of output.
Signed-off-by: Daniel J Walsh<EMAIL_ADDRESS>

Fixes https://github.com/containers/libpod/issues/2388

LGTM and prefer over #2389

Replaced by https://github.com/containers/libpod/pull/2389


how can i set emotion for the whole sentence, not just for words?

seeking for help, if any one knows

maybe do sentimental analysis result as emotion string?

The simple way for now is to take a Bark voice and generate samples and save those samples a new versions of the voice. With patience and a bit of luck you can get a version of the original voice that has a different emotion.


feat(qa): Update IIBs to build v4.4.0-11 & re-enable few tests on P/Z

This PR updates index images (used for ACS deployment via downstream builds) for ppc64le and s390x platforms. Also re-enables tests disabled in #10202.

/test powervs-4-12-qa-ebpf-e2e-tests
/test powervs-4-13-qa-ebpf-e2e-tests
/test powervs-qa-ebpf-e2e-tests
/test powervs-4-15-qa-ebpf-e2e-tests

/test powervs-4-12-qa-ebpf-e2e-tests
/test powervs-4-13-qa-ebpf-e2e-tests
/test powervs-qa-ebpf-e2e-tests
/test powervs-4-15-qa-ebpf-e2e-tests

/test powervs-4-12-qa-ebpf-e2e-tests
/test powervs-4-13-qa-ebpf-e2e-tests

/test powervs-4-12-qa-ebpf-e2e-tests
/test powervs-4-13-qa-ebpf-e2e-tests
/test powervs-qa-ebpf-e2e-tests
/test powervs-4-15-qa-ebpf-e2e-tests

/test powervs-4-12-qa-corebpf-e2e-tests
/test powervs-4-13-qa-corebpf-e2e-tests
/test powervs-qa-corebpf-e2e-tests
/test powervs-4-15-qa-corebpf-e2e-tests
/test ibmcloudz-4-14-qa-e2e-tests

@robbycochran @gavin-stackrox can you kindly review this PR?

@robbycochran @gavin-stackrox can you kindly review this PR?

@pratham-m are you OK with the test failures?

@robbycochran @gavin-stackrox can you kindly review this PR?

@pratham-m are you OK with the test failures?

Yes. only DefaultPoliciesTest is failing due to recent changes in code to use non-MA image. I am working to add fix for the same.

Merging. DefaultPoliciesTest will be pushed separately.


Nice!view compatible pinout

since nice!view is released, and there will be a new board designed for nice!view in the future. I will make a version with compatible pinout of nice!view. so if in the future nice!view is Out of stock or some people find it expensive, my breakout can be an alternative. just like nrfmicro is an alternative to nice!nano. Also will reducing component just like nice!view schematic since nicell said the resistors isn't necessary.

updated with nice!view compatible pinout


Make it easier to manually trigger CI runs on third party PRs

Currently triggering a manual CI run on third party PRs requires a developer to navigate to various pages of the Classis Jenkins UI and search for the PR by its number, then click the "Launch new build" button. This issue gathers some options we could implement to make this user experience better.
Ordered from easiest to implement to hardest to implement:

Send a status report to GitHub when a new commit is pushed to a third party PR

Developer flow: "details" on status notification, then click the replay button

Since clicking the replay button is a user action, the current filtering logic will let the replayed build run

Since each status notification is associated with a commit hash natively, we can handle the per-hash allowlisting of PR commits without needing the developer to input hashes manually

Send status report with custom target URL

Developer flow: Clicking on the "details" URL launches a new build automatically

Pros: One less click! + the pros of the solution above
Cons: No way to rename the link, "Details" might be misleading

Explain the function of the URL in the Context/Description of the status

Triggering the CI build using a specially formatted developer comment

Needs extra logic to associate with commit hash

Manual copying of hash by developers seems cumbersome

Trigger CI build upon review approval by a team member

Needs extra logic to associate review approval with commit hashes

Implement a custom button using the Checks API

The prerequisites for this are tracked in #133

Needs extra logic to associate with commit hash

For both of these, can't it just be based on timestamps, i.e. special comment or approval that is more recent than the commit, and CI hasn't run on that commit? i.e. all we want to do is avoid running the CI on a commit that is newer than the comment or the approval

Triggering the CI build using a specially formatted developer comment

This has my preference. It doesn't involve any navigation of CI systems. It means I don't need to be on the internal Arm network to start on the internal CI. It makes the association between the approved commit ID and the commit ID that the CI will pick straightforward.

Manual copying of hash by developers seems cumbersome

It's easy to grab the hash from the github interface. Just please allow copy-pasting the whole URL.


Add selection by user status

Add four actions to add users to selection based on audio, video, hand raise, and spotlight statuses.

try out find or filter

@ashgreen I made a slight git mess, but I think I cleaned it up. Please let me know if you have questions or merge when you're ready.


Large Test File

Before we launch this, we should probably make sure that this app functions properly on a transfer file of size 200. Technically it should be able to handle about 240 without exceeding 50% of the block gas limit.
This transfer file should have unique recipients (for an actual real live airdrop), but doesn't need to have so many distinct tokens (say 10).
We could check that we aren't double querying the token data. Any lag that is experienced is assumed to be for the ens name resolution (which we can't really avoid). I wonder if it makes sense to include a toggle which enables or disables the ens features for larger transfer files.

The block gas limit was recently increased so we could easily get to 250 by this point. I will try and dig up my simulations from before to see if we can push further but I think 250 as a warning limit is already quite reasonable. Of course the user could probably push beyond up to nearly 500 if they are willing to pay the gas for a whole block.

My PR #92 should improve this huge file alot already.
But as we agreed on I will implement a threshold of unique receiver addresses of ~10-20. If this is exceeded by the transfers the lookup will be disabled and optionally a warning displayed.
This works fine without any ENS lookup anyway.

Cool. I think we can release v1 with this and post in the forum that we have some planned improvements, but that they aren't "release blocking"


Uninstall in Ubuntu

Hi, i remove app from my Ubuntu. But every 10 minutes i see notification in small window, see screenshot https://ibb.co/cm6vd6 How to remove it?

It seems that some daemon is still running in the background.


fix: readme link

Is it right that anyone, not necessarily the repository maintainer, can review someone else's PR?

You can review it, but that doesn't do anything. Me or another maintainer have to review and merge the PR.


Toil is not using TOIL_SLURM_ARGS environment variable

Hello,
We are using slurm/16.05.8 in our cluster. I have set the TOIL_SLURM_ARGS in my environment as -t 2-00:00:00 -q mediumq however toil is submitting the jobs into the default partition which is longq. I have also tried -t 2-00:00:00 -p mediumq but no luck. In logDebug it says:
DEBUG - Running ['sbatch', '-Q', '-J', 'toil_job_1', '--mem=8192', '--cpus-per-task=1', ...

Hello @berguner , what was the fix?

Hello,
I was setting the environment variable by using "declare" in my ".bashrc".
I should have used "export" or "declare -x" for python to see it.
Best,
Bekir
On Nov 28, 2017 16:43, "Michael R. Crusoe"<EMAIL_ADDRESS>wrote:

Hello @berguner https://github.com/berguner , what was the fix?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/BD2KGenomics/toil/issues/1962#issuecomment-347564514,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWI0YyB6EihJfxET_R7I8MAc99zY74A6ks5s7CokgaJpZM4QfE_y
.

Thank you @berguner
I think http://toil.readthedocs.io/en/3.12.0/running/hpcEnvironments.html needs expansion with examples as the information is spread across that page http://toil.readthedocs.io/en/3.12.0/appendices/environment_vars.html and http://toil.readthedocs.io/en/3.12.0/running/cli.html


HSEARCH-2587 Sort DSL on embedded fields throws NPE

https://hibernate.atlassian.net/browse/HSEARCH-2587

merged, thanks! I rename that method and removed the unwrapping.


(ci): build fatpack based on lean image

This is a quick draft I came up with, don't think it will work yet, but trying to get out the idea.
This is the idea described in #4441
The only difference between the lean and the fat image is the blitz.fatpack.sh script. So we could build a lean image and then a fatpack on top of it.
This should shorten build times for the fatpack and make it (hopefully) possible to build the fatpack in github actions.

Thats a good idea - hope it works :)

If unpacking the image in the action (on the github runner) gets into space issues can use this hack which should be able to accommodate even the 30GB+ unpecked image: https://github.com/easimon/maximize-build-space
Already used for the amd64 image with desktop:
https://github.com/raspiblitz/raspiblitz/blob/b02db0b46c6466fc2d7ac278fdf5518c383b478f/.github/workflows/amd64-lean-image.yml#L34-L38

Will be continued in #4465


Added inventory manager nbt support

Added two functions to work with nbt, closes #317
The old functions are unchanged, the new ones work the same, but support nbt tags.

I'll review this when I get back home in a week

Looking good - I don't see any issues so far

Would you want to add this to the ap documentation? https://github.com/Seniorendi/Advanced-Peripherals-Documentation

Yes, I'll do it soon


Support spring cloud vnet injection

This PR supports creating a VNet-injected Azure Spring Cloud service. It add the following parameters in az spring-cloud create

vnet (OPTIONAL): User can specify a name or resource id of an existing VNet.

If only a name given, it will format the resource ID using ASC's subscription id and resource group.
If app-subnet and service-runtime-subnet are both provided, this field can be omitted.

app-subnet (REQUIRED): User can specify a name or subnet resource id. If only a name given, the vnet must be provided.

Cannot be a same one as service-runtime-subnet.

app-network-resource-group(OPTIONAL): A resource group where all network resources related to app will be created in.
service-runtime-subnet(REQUIRED): User can specify a name or subnet resource id. If only a name given, the vnet must be provided.

Cannot be a same one as app-subnet.

service-runtime-network-resource-group(OPTIONAL): A resource group where all network resources related to service runtime will be created in.
reserved-cidr-range(OPTIONAL): Specify 3 unused /16 IP ranges (e.g. <IP_ADDRESS>/16,<IP_ADDRESS>/16,<IP_ADDRESS>/16), which are not overlapped with any network elements in the whole customer’s network environment. Azure Spring Cloud uses the IP ranges for hosting underlying infrastructure.
If user doesn't set this value, CLI should parse VNet's ip_addresses, and set the value to 3 CIDR ranges non-overlap with vnet.address_space.ip_addresses. If the vnet's ip addresses do not have such space left, CLI should raise an error and ask for the user input. This set operation requires NetworkClient in validator.

Here add validator to validate:

Two subnets must in the same VNet
Two subnets must not be the same subnet.
CIDR range must has 3  /16 IP ranges.
If CIDR range is 3 IP ranges, validate they DO NOT overlap with each other.
CIDR is valid IPv4 network.

It doesn't validate:

Whether the subnets are exist or not
Whether the subnets are used or not
CIDR are used or not.

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

If this PR is for a new extension or change to an existing extension, use the following to try out the changes in this PR:
docker run -it microsoft/azure-cli:latest
export EXT=<NAME>
pip install --upgrade --target ~/.azure/cliextensions/$EXT "git+https://github.com/VSChina/azure-cli-extensions.git@yuwzho/vnet#subdirectory=src/$EXT&egg=$EXT"

spring cloud

rebase 0.2.4 version

rebase 0.3.0 version

LGTM

/azp run

What's the status of this PR? Is it ready for review?

@yucwan what's next step plan of this PR? will someone else pick it up?

@yuwzho As VNet API is already in production. Shall we proceed and merge this pr now?

@yuwzho As VNet API is already in production. Shall we proceed and merge this pr now?

I will publish this draft once the backend full ready.

What's the status of this PR? Is it ready for review?

@fengzhou-msft Just published the PR, please help me to review it. Thanks.


Remove stale build badges from README

These badges are updated regularly. Could you please explain why you think they're stale?

Maybe I'm wrong to say they are stale. Usually build results are linked and visible for open source projects and there isn't a link offered for these badges.


rl_order_execution can not work on "subproc" mode on Windows

🐛 Bug Description
rl_order_execution can not work on "subproc" mode on Windows.
To Reproduce
Steps to reproduce the behavior:
1.I run the demo with: python -m qlib.rl.contrib.train_onpolicy --config_path exp_configs/train_opds.yml --run_backtest
2.it works normally with the default config exp_configs/train_opds.yml which set "parallel_mode: dummy"
3. However, it doesn't work after I changed the config from "parallel_mode: dummy" to "parallel_mode: subproc". It works on Linux, but it does not work on Windows.
Expected Behavior
The exception is raised by different behavior of multiprocessing between Linux and Windows.
Screenshot

Environment
Windows
AMD64
Windows-10-10.0.22631-SP0
10.0.22631
Python version: 3.8.19 (default, Mar 20 2024, 19:55:45) [MSC v.1916 64 bit (AMD64)]
Qlib version: 0.9.3
numpy==1.23.5
pandas==1.5.3
scipy==1.10.1
requests==2.31.0
sacred==0.8.5
python-socketio==5.11.1
redis==5.0.3
python-redis-lock==4.0.0
schedule==1.2.1
cvxpy==1.4.2
hyperopt==0.1.2
fire==0.6.0
statsmodels==0.14.1
xlrd==2.0.1
plotly==5.20.0
matplotlib==3.7.5
tables==3.8.0
pyyaml==6.0.1
mlflow==1.30.0
tqdm==4.66.2
loguru==0.7.2
lightgbm==4.3.0
tornado==6.2
joblib==1.3.2
fire==0.6.0
ruamel.yaml==0.18.6

Thanks, I think should be stated clear in the documentation.


bugfix: fix find target class issue if scan the web scope bean such a…

…s session scope ben

Ⅰ. Describe what this PR did
when a session scope bean (or other web scope bean) is called by SpringProxyUtils.findTargetClass, it will throw exception as the code "targetSource.getTarget()" will call 'org.springframework.beans.factory.config.Scope' to get bean instance.
Ⅱ. Does this pull request fix one issue?

#1168
Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #1262 into develop will decrease coverage by 0.03%.
The diff coverage is 0%.

@@              Coverage Diff              @@
##             develop    #1262      +/-   ##
=============================================
- Coverage      49.47%   49.43%   -0.04%
  Complexity      1651     1651
=============================================
  Files            326      326
  Lines          11439    11439
  Branches        1415     1415
=============================================
- Hits            5659     5655       -4
- Misses          5153     5155       +2
- Partials         627      629       +2

Impacted Files
Coverage Δ
Complexity Δ

...in/java/io/seata/spring/util/SpringProxyUtils.java
3.7% <0%> (ø)
3 <0> (ø)
:arrow_down:

...server/store/file/FileTransactionStoreManager.java
45.99% <0%> (-1.4%)
19% <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 1c5bf9d...7856e3d. Read the comment docs.


build: make all components are standalone

When migrating to Angular v19 some components were marked as not-standalone by the migration schematic. However they can be standalone.
Also enables the flag to ensure all components are standalone

#849  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


Setup a benchmark system to help gauge the relevance of vector search

Currently we are looking at a number of techniques to improve the performance of vector search. The problem is we need a way to benchmark if the performance is indeed better, and by how much. This task it to create performance benchmark for vector search to ensure that whenever we add / remove a feature (e.g. hybrid search vs semantic search), we are getting back better vector search results.

Users of Cassandra are reporting up to a 30% recall drop for ANN over KNN with 1M vectors. This is unacceptably high - we need have basic recall and precision tests for knn.

@alexleventer Add notebook for precision and recall to this ticket

ANN Recall Metric Notebook - https://github.com/pinecone-io/examples/blob/111899e7cd447ef948dbd7ec22d1c8217a1f2a1f/bert_search_test/bertcomparison.ipynb

https://medium.com/@m_n_malaeb/recall-and-precision-at-k-for-recommender-systems-618483226c54