Closed JacoboSanchez closed 2 years ago
The entity_id's are generated from the user-readable names. What I can do is to more dynamically generate those names
Proposal:
#1
, #2
, and so on. "Active Power" then becomes Active Power #1
for the first inverter, Active Power #2
for the second inverter, and so on.What I won't do is add extra configuration parameters like a "custom prefix" in the config flow. Such parameters are always rejected by the HA Core team (same thing for allowing a customized update interval, cfr. discussion for Goodwe integration)
I see... I am so used to HACS integrations that I am not really used to HA standards :) . Well my use case is not a common one as I have two isolated inverters managed in my home assistant (they are from different houses). In other integrations I have like the shelly relays I can rename them in the device so they are already imported with a different name but I understand that this is not really possible here and duplication is unavoidable.
I like your proposal and think that would help users. At least making something different for the power meter would help to more recent users that already have trouble with the concept of input power vs active power vs power meter active power.
Thanks for your time answering, you are doing a really great work with the integration (and with the register write feature). I am currently figuring out how to connect a modbus-rtu to modbus-tcp device to the inverter to avoid the unstable one they have for the app... that way write permission would be out of the box without authentication I guess
Totally off topic but finally I was able to connect to the inverter using modbus tcp without using the fusion solar port provided by huawei. I used an Elfin-EW11 device to connect to the inverter using modbus-rtu and forwarding it to a modbus-tcp. Did not tried writing registers yet but seems to be an easy alternative to connecting to internal wifi once port 502 is closed in latests firmwares
Can you let me know how you connected your rtu-to-tcp dongle? Which pins did you connect?
Of course. I will post an overview of the process you can ask me any question later.
I have two inverters in two different places, this test was made in the one without batteries. The inverter has firmware 109 so port 502 is still available but I wanted to try this before thinking on update.
I opened the communication cable protection and meter was inserted at pins 1 and 2. I have read somewhere that it should be in 3 and 4 and that firmware 117 would not accept it at 1 and 2 so I switched them to 3 and 4 and used "pv monitor app" (fusion solar asks me to update firmware) to make the inverter detect the meter again.
Then I powered the EW11 with 5v and inserted a shielded network cable to pins 1 and 2 of the inverter going to the EW11 (pin1 to B- and pin 2 to A+). Configured the EW11 in the web page to connect to my wifi as station. Configured a modbus tcp at port 8899
Then configured the serial section with 9600 bauds
Finally connected the integration (currently still a custom version of emil's one) to EW11 ip, port 8899 and slave id 1
I need to see the connections from the inverter with batteries... I think they both meter and batteries should go to 3 and 4 while modbus-rtu clients like the EW11 go to 1 and 2
About connections on EW11 I bought it with an adapter but you can make the connections by yourself with ethernet cable
It is up only for 3h so I can not say anything about stability/durability but currently it is working
Ok, so you aren't using the GND/EN+ (12V) pins, that was what I was wondering about.
I guess you are talking about Abnormal status of power meter after upgrade to SPC117 firmware version on SUN2000 (2-6)KTL-L1 inverters ? I already checked my communication cable, and on 485B2/485A2 (ports 3/4) it has the wires to my LUNA2000 battery attached, while the 485B1/485A1 (ports 1/2) have the wires from the power meter attached.
I just had to do the upgrade to SPC117, and indeed: the power meter values are frozen now. I'll have to rewire the communication cable to get it working again.
Using gnd at least seems to be a good practice but as I had a 5v source near the device (for an ESP32 controlling the garage door) and the meter did not use it then decided to try that way... will think about it for the second inverter. However I don't really knew about that 12v pin you are talking about (which one is it?) EDIT: I found it: pin 6... the diagram I had showed 5 and 6 as GND...probably from another version...
I wish it was that post as the ones I read did not specified how to do the re-discover process and had to figure out that part by myself
Did a test with a multimeter and was not able to get a 12V reading between pins 6-7 I may not have tested correctly because I had not good sight on the connector but looking at the diagram it seems to be an enable pin for the battery so maybe it only sets 12v state when sending the enable signal to the battery? I don't have a power source near the second inverter so I was excited with this... however it does not seems to be usable
Describe your feature request
When you configure one inverter you get two active power sensors. Home assistant renames one to active_power and the other one to active_power_1. This may be confusing at first to differenciate without looking at the parent entity but you can handle it without problems.
When you have two inverters you get also active_power_2 and active_power_3 and all the other sensors to _2 which refer to one or other inverter depending on the order you added them. This is a bit more problematic to manage in the long term remembering which one is suffixed with _1.
Using an automated prefix would break backwards compatibility and it is also hard to use a good one as inverter model can be also duplicated and serial number is not very human friendly.
I would like better to have an optional alias parameter to label the inverter's generated sensors with a custom prefix you can remember when using the sensors in cards/automations and so on
NOTE: I am waiting for a more final version to migrate and only temporary tested your login and write branch so I apologize if this do not applies to the main branch