Names and device #28
Labels
enhancement
New feature or request
Comments
|
We are using the default names we get from wemportal api or Web. If you want you can just go ahead and rename your entities however you prefer. |
|
Fixing naming is quite hard in this case. By dynamically combining data from API and website there are a lot of naming conflicts, which can't be resolved with simple logic. To get everything fixed I would probably need to hard code a lot of things. There is also the problem with different devices having different entities and settings, which complicates this further. For now, I will focus on improving the functionality and leave the naming when everything else works sufficiently well.
Prefixes are used for entities that are scraped from the WEM portal website. Prefixes are the categories that can be seen on the website and are there to help you narrow down what the entity name actually means.
This sounds like a good idea. Will add this, but can't provide an accurate time frame.
I think that Home Assistant developers discourage this. Grouping the entities into a device should solve this anyway. |
|
Thank you both for the quick answer. I fully agree, that device is the right thing. Once it comes naming won't be a big issue anymore. "Could you maybe add a "Heat Pump" device? Should I leave this ticket open for "Heat Pump" device, or close it and create a new one? |
|
You can leave it open |
|
Device support is finally here and should be released soon after I test it out. If anyone is interested in testing:
|
|
Is there anything we need to know if we Test it. Any migration steps needed? Or just straight forward? |
|
It will probably brake names of entities ( append 2 at the end because entity with that name already exists). Other than that everything should work fine. |
|
And will brake history aswell, right? Maybe we should think about an entity migration so that people are not losing their history!? |
|
Maybe something like we did here: dm82m/hass-Deltasol-KM2@9a500f3 |
|
Looks good, will add this. |
erikkastelec
added a commit
that referenced
this issue
Mar 8, 2023
|
migration seems not to work, I tried the dev branch on a clean install. started with current released version and then migrated to dev branch. old sensors will get state "restored" and new sensors are created. maybe this has something to do with changing from yaml config to config flow? not sure tbh. I also get no info logs about entity migration, I guess something is not good there. |
|
Interesting, I did the same and it worked. Will spin up a new instance, see if I can reproduce this and keep you posted. |
|
It should work now. Thank you for taking the time to test this. |
|
|
|
|
some of the entities are migrated but a lot of the old sensors will become restored:
|
|
and with release version I get >80 sensors and with dev version there are only 29 sensors... |
|
Did you change mode to both inside Home Assistant configurations? |
|
no I did not ... sorry for that! tested it now and only a few sensors restored:
|
|
I believe these sensors were created when the new integration was first set up with mode=api. When the mode changes, the names of some entities may also change. For now, I will leave them as is for now. Since these are newly created sensors, we won't lose any old historical data. It's just a little inconvenient to delete them. |
|
okay, moved my production instance to dev branch. it would be great if the options would be directly changeable on initial setup. currently I manually need to change them later on. and there is a typo: |
|
I would prefer if people read the documentation. If we put this information in the initial setup, many people may choose scan intervals that are too small and then wonder why the integration stops working after only a few hours. However, since this is a one-time setup, I don't think it should bother anyone too much. |
|
you should also switch the async_get to remove the deprecation warning: dm82m/hass-Deltasol-KM2@480fdf3 so far again thank you for all the work! :) |
erikkastelec
added a commit
that referenced
this issue
Mar 10, 2023
|
Done, thanks for the reminder. |
erikkastelec
added a commit
that referenced
this issue
Mar 15, 2023
|
This update should fix the api not being replaced with a new instance on failure |
|
Looks good so far. The only thing I got was this: |
|
Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht Logger: custom_components.wemportal 'NoneType' object has no attribute 'status_code' |
|
Also a Integration restart is not helping: Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht Logger: homeassistant.config_entries Error setting up entry [email protected] for wemportal |
erikkastelec
added a commit
that referenced
this issue
Mar 23, 2023
|
This should fix the issue. I think that this was also the reason behind "Can't find ..." errors you reported previously. |
|
Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht Logger: homeassistant Error doing job: Task exception was never retrieved |
erikkastelec
added a commit
that referenced
this issue
Mar 25, 2023
|
The last bug should be fixed. Thanks again for your feedback. |
|
after this happens, it stays broke and will not get restored. |
|
Will look into this. I encountered a similar problem. |
|
Occurred again |
|
Any idea what’s next? Due to migration of entities I can’t get back to stable. |
|
Even Restart of integration is giving that: Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht Logger: homeassistant.config_entries Error setting up entry [email protected] for wemportal |
|
Expect a fix today |
erikkastelec
added a commit
that referenced
this issue
Mar 30, 2023
|
Again gets offline: Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht Logger: custom_components.wemportal Can't find f7ad0827d125d6220474a66849c330ae:4813:outside_temperature |
erikkastelec
added a commit
that referenced
this issue
Mar 31, 2023
|
Again: Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht Logger: custom_components.wemportal Can't find f7ad0827d125d6220474a66849c330ae:4813:outside_temperature |
|
Any update Erik? Sorry bothering you, but as you know - I can’t step back to old version so I am relying on your updates. 🥴 |
|
This should solve the problem. Entities should be unavailable for maximum of one api scan interval if there is some unknown error, for any known errors there should be no downtime. I will keep testing for underlying problem, but we seem to get a bunch of different error codes or no response at all when session expires. Thanks for your patience. |
|
error is back and not recovering: |
|
Hope this helps. If not, I will have to look into this further and possibly rewrite some things. |
|
Looks good so far! 🚀👍 |
|
Hey @dm82m , I haven't had any issues since the last update. Have you? If not, I will be moving the new version to the main branch. Thank you again for all the help testing this |
|
Sometimes values wenting offline but integration recovers itself. So for me you can release it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First of all: thanks for your great project.
In "both" mode, I see 78 wemportal entities and I am bit lost between them. Some of them are in german, some in english due to issue #22. Some of them have a prefix of "heat_pump", "heating_circuits" or "wez", others have none of these.
Could you maybe add a "Heat Pump" device? That would allow to add all entities to an area in one step. Also all sensors or all controls could be added to a dashboard in one step.
Otherwise, I suggest to add some common entity prefixes that can be used in entity filtering of the lovelace cards. Something like:
The text was updated successfully, but these errors were encountered: