Naming Scheme standardization #45
Replies: 12 comments 21 replies
-
|
I understand your reasoning and don't have a problem. The entity names for my inverter were based solely on the terms used by the manufacturer but Working Status or Working State means the same things and I can get used to any changes for benefits down the line. |
Beta Was this translation helpful? Give feedback.
-
|
With this particular thing status/state it is on the edge that's right but the general idea (in the sw dev community) is:
And I know it wont tell you much :-D But it is what it is... :-D I hate it too sometimes... hm, maybe more often than that... State is for: Idle, Running, standby and status for everything else (often even more descriptive, in more words, etc.) Sometimes is status also used as a description for a state. But one could argue what sense it has if you need to provide a f*cking explanation for it, right? 😆 Those terms original idea is that they should be self explanatory, lol! |
Beta Was this translation helpful? Give feedback.
-
|
Now I know how to change new sensor names to old entityID’s I haven’t got a problem with your idea. 😄 |
Beta Was this translation helpful? Give feedback.
-
|
They way how you described it here would erase history of that, is that a typo? 😆 And you were just referring to that small manual in wiki? 😆 |
Beta Was this translation helpful? Give feedback.
-
|
I deleted the old sensor. No history data was lost. |
Beta Was this translation helpful? Give feedback.
-
|
You can do it the other way around too! :) |
Beta Was this translation helpful? Give feedback.
-
|
Oh well, I thought it would be better this way and might be more safe for future updates of the definition file. I might be wrong and hope that I haven’t got to repeat this process for each version update. Still learning 😫 |
Beta Was this translation helpful? Give feedback.
-
|
No only when you delete the device 😆 And in terms of safety they are the same. |
Beta Was this translation helpful? Give feedback.
-
|
I was just having a look at the first batch of naming changes, realised that this is much harder than it seems... As a sensor name I'm not convinced today_production makes sense when the friendly name is today's production, shouldn't it be todays_production? A second observation is that if your database stores say 14 days worth of data then todays production is only correct for today. When you look at archive data then daily production makes more sense as it works for everyday including today? I'm also wondering whether the destination/source of the data should be included to be 100% clear. For instance what is Load; house load, grid load? Leads to perhaps PV Production I"m not trying to be a pedant just an observation and wondered if a set of proposed naming and their meaning could be discussed here and hopefully owners can confirm that the naming makes sense for their inverter/battery setup? |
Beta Was this translation helpful? Give feedback.
-
This is really a matter of HA, grammar and so. Originally I tried to just use "Today's" but HA will translate it into entity_id as "today_s_" which for a matter of searching entity names within the HA was awful. On the other hand "todays" is misleading as it means without the "'" totally different thing. That's why i kept the searchable name as is and added friendly name to make it look right. As always you are not forced to use it.
You have to look at the sensors as they are from the point of view of the Inverter device. Inverter also calls the sensors as today and I wanted to preserve this link so it is obvious what value it is. It became Daily sensor later in the HA when HA starts to record the data and then you can look at daily statistics of today's sensor.
When comes to this or at least how did I understood the idea of how inverter maker presents it the load os only one. What separates now from over time is power and energy respectively. There are no separated sensors for what you are asking (Even if that would be great I would love to know when is battery charged from the PV and when on the other hand from the grid but it is what it is) and there is no easy way how to maybe program this as an addition. There is even long thread on the HA github's about the Energy Dashboard and that people would like to know source of the energy there with no clear solution or answer from the devs. And not really sure if I follow your examples :-/ Load is here really only one just the source of the energy which satisfies the load changes. Battery Charging/Discharging should be called Import/Export but I don't really want to change what's programed in the inverter (Really only in some rare cases). Also not really fan of labeling anything there as "Home", it's just the Load and then maybe UPS Load. Cause you are not strictly have to use it in your home it can be also your workplace and such. :)
That's okay, it's purpose of this thread so... I was not sure for a long time either but i think I was so far somehow successful in finding common middle ground but I still want to hear others opinions. The inverters and batteries are kinda only one setup and generalization always have some niche cases. You will never satisfy all minds and that's why we have custom profiles. So you can use the generalized profiles and adjust them. But I'm sure that adjusting all profiles to name sensors the same way is the right path cause when I look into some I'm usually not even sure what I'm looking at cause it's often not even clear what some sensors mean. And I kinda have to know cause I should be able to help others understand and such.
That's why I added a description attribute to some sensors. So the sensor can be thoroughly described. But at the end you will never be 100% sure where the power or energy really comes from. You would have to record way more data than it currently does to determine that and I think it is way over the scope of this code. Edit: Anyway, even I really think it makes the most sense this way I still welcome anyone to challenge those ideas cause I also want to know when I'm wrong. |
Beta Was this translation helpful? Give feedback.
-
|
I guess it depends totally on the inverter/battery manufacturer and even your native language. Some terms translate better than others. I've been looking at my Tesla Powerwall Battery and the official HA integration to see what terms they use. Interestingly it does not use the term today or daily, it just identifies the value. I can see the logic here as whether it's today, daily, weekly or monthly depends on how you query and present the data. If you ask for the data from 00:00 to now then it's todays, otherwise it's yesterdays, or last weeks! The HA Energy does all this for you so why name the sensor today at all? As for terms:- and then import/export is added depending on the direction, obviously some combinations make no sense e.g. Solar Import My Solis inverter uses the term grid rather than site and PV rather than Solar otherwise similar. However, if you ask 10 cooks how to make an omelette you'll probably get 10 answers but they all taste great 😆 |
Beta Was this translation helpful? Give feedback.
-
I'm not translating anything my inverter literally says Today and Total, And Today is just total sensor which resets every day. I'm telling you forget what HA does and look at it just from the inverter perspective it gives you a value which represents today let's say production. He does not give you any history and so. So they named it correctly.
Let's be accurate here. What data from which sensor you mean? Cause I can't think of any which would be valid. You are proly mistaking data source and what those data represents over time. You want to have data source named according to what data you can read from it? That really does not makes sense cause then you would have long ass name cause Total sensor would have to be then named like: "Hourly Daily Weekly Monthly Yearly Production". Cause those are all the stats you can extract from that sensors data over time.
Yes because it has one from which you by recording and then querying you make all those respectively. But all the inverters within the solarman world works +- the same and has distinguished values for that.
Cause inverter has that value. And integration provides data from the inverter 1:1 (But I also don't know why they have separated sensor for that...).So as I told you to correctly represent what value from the inverter. I'm really not trying to see logic in there after my experience with the solarman protocol. It's the worst piece of SW I ever saw. And I saw some nasty shit before! :-D You are going on it really from wrong direction. I know its HA integration but forget about HA in our case cause we are doing integration layer between inverter and HA then you can do whatever you want with the values.
I know what those terms mean I did not understood what you were trying to say.
Import/Export has here rather special meaning in terms of how is it used in energy world. They really call it that way. Energy you buy is imported and energy you sell is exported. So I don't really see benefit of transferring that onto other relations for example Battery. There it really makes more sense to use charged - discharged.
All of them use this terminology. (at least what I saw so far)
But you described Site before as whole system (batt included) now you say that it's a grid? I don't follow. 😢
True but from sw dev point of view and maintainability there are some ways how to things correctly and wrong, better and worse. One bad example would be bringing there feelings instead of reason, 😆 I try to explain it once more as clearly as possible. Integration should provide sensor values as is without any personalization. That comes after in the HA. This integration simply gives you values in the most clear and accurate way possible. That means if in the display of the inverter you see Today integration should also say Today. And you can make it Daily in the HA. But you can see daily statistics from Total sensor too so It really does not make any sense to me why to bring statistics terms in the naming when that's above the sensors itself. And comes after, after you gather sufficient amount of data. Single stamp from the sensor in kWh for example won't give you any daily data. Multiple stamps of them does. But that happens in the HA. Not in the inverter and not in the integration. |
Beta Was this translation helpful? Give feedback.
-
|
I think we'll have to agree to disagree 😄 When I mentioned translation I was wondering whether different terms get used in different countries? For instance in the UK we have power stations with generators inside, therefore they generate electricity not produce. We naturally use the same term for Solar, it generates not produces. We would use the term production more for a factory that makes things. This is not to say that the term production is not used in the electricity context and you'll find many examples of both! When you have an AC couple system like I do the inverter is very dumb, it has no idea what is being imported or exported to the grid nor where the energy is being used. It has no idea if there is a battery in the system or what the house load is. My viewpoint is therefore skewed towards the Tesla Powerwall and I'm very used to the terms used by it. So the battery has a charge level and it is either being charged or discharged. However when you talk about energy then it moves to the electrical domain and says it has exported or imported kWh. Which is why I believe the electrical terms of import/export should be used for all electrical flows irrespective of the technology used to store or generate it but it's just my viewpoint. Hopefully someone else may take an interest and add some thoughts, this would be much easier over a beer!! |
Beta Was this translation helpful? Give feedback.
-
|
The most correct way would be to just have Total Solar and Today's Solar or Total PV and Today's PV (the second one is more conforming with the other sensors). Cause it can't mean really anything else than it's generated or produced (transformed). But that would have even more people complaining. 😆
They do both though. And if you want to be really correct they transform the energy (from mechanical/chemical to electrical let's say). Energy can't be either created(generated) nor destroyed.
If it has no idea then it can't have those sensors right? And thus even mentioning it here has no place, right?
But we are talking about totally different device here so I don't understand you.
So true. I'll get back to you when I'm in England. 😆 That's what I'm talking about. You obviously want to have things the way you are used to. Or how you feel is right. I'm simply trying to follow docs about our devices. Edit: And my opinion is that naming from your Tesla Powerwall is for sure more correct than the one from solarman/inverters as there it's all translated from Chinese. There is plenty of typos or wrong order of words. And I'm really fighting with myself every time I see it. That being said my English is also far from perfect. 😆 |
Beta Was this translation helpful? Give feedback.
-
|
I wonder what will happen after 120V people will join the convo... 😆 |
Beta Was this translation helpful? Give feedback.
-
|
I have to address one thing again. I thought that it's obvious that not all terms are relevant with all inverters. Cause you @gedger said that for example grid import/export or battery charged/discharged has no meaning in the setup of your device and I thought that it's obvious if your device doesn't even have those sensors is meaningless to discuss naming of those in regards to your device. Or am I missing something? 😆 |
Beta Was this translation helpful? Give feedback.
-
|
Version 24.08.14 will proly also contain renames of bought/sold sensors to import/export sensors for your device, but there is very simple way how to do it properly. Before you will update to that version, do the renaming and then update. It will affects 4 sensors and it should be the last pain the ass for you. 😆 I'll give you more info when it will be actual! 😉 |
Beta Was this translation helpful? Give feedback.
-
|
Yes, renaming before updating will make it easier and keeps history. After that all my dashboard and automations and whatever need to be renamed. |
Beta Was this translation helpful? Give feedback.
-
|
Cmon! When you display the dashboard in yaml and use find and replace feature (I'd say that those names given the fact they contain name of the device and so are unique enough to rely on that) it has to be matter of seconds to deal with it! And I know cause I did it maaaaaaaaany times before! 😆 And this change will also affects me, so. 😆 I'm slowly starting to use also other devices with my integration and I'm now even more sure that having names standardized will be + for everyone cause imagine you have multiple different devices. You would not find it better that all of them provides values with same purpose under the same sensor names? Edit: Anyway when anything regards naming changes in new version I will for sure state it in the update notes so you will know! |
Beta Was this translation helpful? Give feedback.
-
|
refactor: Third batch of name standardization But I won't do any new release (not even pre-release) until 14.8.2024 which will be v24.08.14. |
Beta Was this translation helpful? Give feedback.
-
|
Before updating from Was that the proper way of updating? |
Beta Was this translation helpful? Give feedback.
-
|
Try remove the device and add back again? Maybe that step really is mandatory at the end... |
Beta Was this translation helpful? Give feedback.
-
|
It seems so. After removing and adding it back, it used the renamed instances and the |
Beta Was this translation helpful? Give feedback.
-
|
Wait 24 hours and then go to settings/entities and click on the entity_2 entry, then the config icon and it should have detected that it's no longer being used and provide a delete option....IIRC |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I already deleted those. It seems it's the remove/re-add the device step that was missing. |
Beta Was this translation helpful? Give feedback.
-
|
This probably happened because the entityID already existed with history data in the database. Home Assistant added a _2 to it to prevent overwriting. As far as I know you can delete entityID's only by deleting them directly in the database but don't ask me how to do that. |
Beta Was this translation helpful? Give feedback.
-
|
Hi! |
Beta Was this translation helpful? Give feedback.
-
|
I just entered the German translations for the sensors. You might want to wait until David supports multilanguage. Here is the first set: |
Beta Was this translation helpful? Give feedback.
-
|
Renaming of the entity_ids is not the problem here. That should be fine. What will cause the issues is that device deletion and re-adding it back again. |
Beta Was this translation helpful? Give feedback.
-
|
OK. Then it's probably better to wait for the translation. 😉 |
Beta Was this translation helpful? Give feedback.
-
|
Renaming the new entityIDs from batch nine for ha-solarman version 24.09.26 worked like a charm and kept history data from previous entityIDs 😄 Before update:
Update to new version and everything is fine.
Thanks for your continuous hard work to make this integration the best and easiest way to implement a variety of different hardware into Home Assistant. Great job! 💜 |
Beta Was this translation helpful? Give feedback.
-
|
Yes I'm doing this exactly the same way! I'm really glad you also had this great experience with it! |
Beta Was this translation helpful? Give feedback.
-
Hello!
I know that some folks here gonna hate me for it but I'm preparing to change some additional entity names in the name of standardization and also for coming feature of register scanning (custom profiles of yours won't be affected ofc).
But I wanted to let you know before hand.
Some of the changes:
And why? It maybe does not look like it at first but to make it more easily customizable in the future from the HA UI. We first need to define some sort of a scheme across all profiles.
Any objections are more than welcomed (as well as suggestions for said standard names).
Cheers!
Beta Was this translation helpful? Give feedback.
All reactions