-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gather serial number #39
Comments
It's not exactly clear to me what the issue is. Can you elaborate?
My firmware (R4.10.35 (6ed292)) reports it but requires installer permissions to read it (I can read the contents). Serial number of what? |
The real issue is how can we filter out dead/removed inverters from Home Assistant. To do that we have to implement a The unique ID can be implemented right now for the Inverter sensor entities has we get the Serial Number for each of the inverters, but right now we don't get the Serial Number for the Envoy device itself (other then when we retrieve My thinking was one way is to get the serial number is from I just would want to find a cleaner solution to get the Envoy serial number to give each sensor in Home Assistant a unique ID regardless if your getting inverter data or not. The only way I can do this is by scraping the
Serial number of Envoy device
To get the serial number, not sure what your output looks like but
Older Envoys don't support this page 😞 |
@gtdiehl - I'm having a hard time following the issues you are bring up. Let's try to separate a few things:
From what I've seen the envoy and each inverter have a serial number set by Enphase which look like they come from the same pool of numbers. which seem to be currently in the 40 bit range, mostly due to a prefix in my case of 121, which is probably some sort of name space partitioning. Since unique ID appears to be a string within Home Assistant, What would be the issue with just using the following to put Enphase serial numbers into a partition of their own?
Do you have a reason to believe Enphase might reuse the serial numbers? Do you think the serial number might in some way be a property of the Envoy and might change if the Envoy was replaced?
If I follow correctly you were suggesting also using the Envoy's serial number to make things more probabilistically unique like:
While this would certainly make things more unique, it would have the side effect of changing all of the inverter unique IDs if the Envoy ever had to be replaced. Off the top of my head, I don't think you'd want to disassociate any/all of the inverter history you have if you have to replace the Envoy.
Separately, What are the issues with getting and using the Envoy serial number from IIRC info.xml is fetched unless the Envoy password is supplied by the user. Any reason not to always attempt to fetch (As I mentioned separately, the envoy sensor created by Envoy Reader, should publish the Envoy serial number, and firmware version info as attributes of the Envoy sensor, so you can see that info within Home Assistant.)
A timestamp of the last time an inverter reported (As I mentioned in another issue, this data should be available within Home Assistant so that it's possible to do alerting, etc.) |
@rct I'll try and answer your points, but before I do maybe I can explain my rationale a different way.
Yes the Inverter serial number is unique enough for each inverter, but not for the other entities that are created for the other monitored conditions such as production, daily_production, etc...
Currently the serial of the Envoy device itself is only retrieved when the inverter data is gathered. And when we do get the serial number we only save the last 6 digits. So currently we really are not storing the entire Envoy serial number. I'm not looking at changing Envoy serial numbers use case as I assumed this value will not change. Replacing the Envoy with another Envoy but with a different serial, well I would expect in that use case that historical data for the old Envoy will not be joined with the new Envoy data in Home Assistant.
My thought (after getting the Envoy serial number) is to really have two ways of creating a unique id. Here
Or something along those lines, as the inverters already have a serial number. The other entities will just have the Envoy serial number appended to the name for the
No issues, I just want to find a possible solution without using authentication. If it is not possible than it just maybe a known limitation. I understand you have mentioned the firmware version and other attributes but as you know we are limited by what the Envoy pages return, and I would not want to scrape data or force the user to get basic information that is from a page that requires authentication. With some Envoys you are locked out of the device by Enphase as the default password is not the last 6 digits of the serial number, such as my device. Here is a link to a tool that I had to use to get my password; Enphase Password
A notification implementation in Home Assistant would be nice but for the user to remove the dead inverter we still have to implement the unique_id() method in the sensor.py code, which means we need to solve the original problem of getting the Envoy device serial number. If we don't have a clean way to get the Envoy serial number that would work across all firmwares than maybe we can have some limitations?
|
Ok, I think I have a better understanding now. This is probably easier to discuss setting aside the individual inverter discussion for now. Looking at the MQTT sensors I'm creating via rtl_433 and MQTT auto discovery, I see what you are talking about and how it should probably work. In order to be able to use the Home Assistant UI to configure, customize, or delete entities (and devices), the entities must each have a unique ID that doesn't change. Currently, this gives the user the option of changing the name or icon, or disabling or deleting the entity from the Hass UI. Additionally, there should be a unique ID for the Envoy device which will enable the HA entities created by Envoy Reader such as production, consumption, etc. sensors to be grouped in the UI as belonging to the parent Envoy device and enable some amount of customization. By tying the entities together to the parent device, a device page is then available in the UI like this:
No scraping should be required. My Envoy IQ (and I'm assuming at least recent versions of the S) return the serial number and firmware version from I have to assume the availability of
Only 6 digits are saved because that is what is needed for the default password for the Some ideas: A user configuration setting could be added to set the Envoy serial number if it can't be obtained. A fallback if both of those options fail, if the user specifies the envoy IP address or hostname in the configuration, it could be assumed to be fairly static and used as part of the Envoy's unique ID string. Is hostname/IP address what is meant by If all of those fail, then just completely skip trying to create a unique ID for the entities, If that makes the code to complex, just create a static string. I'm sure the majority of installations will only have a single Envoy so it should be unique enough. It only needs to be unique within a Home Assistant instance not a globally unique identifier. (Does the current envoy code work if you wanted to have more than one Envoy polled in Home Assistant?)
|
Relying on an assumption that IP address or hostname 'are fairly static' is a 'dangerous' assumption and bad practice. Neither IP address nor hostname should be used for creating a unique ID string (unless that ID can be changed at later moment, in a very simple manner, clearly visible to the user and without any further consequences). |
Home Assistant can remove single entities but the sensor needs to implement a unique ID. This would be helpful when an inverter is removed from the physical system but still reports as part of the envoy inventory.
Since inverter gathering is all or nothing, the filtering would be done through Home Assistant.
One way to retrieve the serial number is through an authenticated page
/prov
just not sure if all firmwares support this page.The text was updated successfully, but these errors were encountered: