TOU settings with ME3000SP

[PaulOckenden]

I have 2 x ME3000SP battery controller/inverters, both using WiFi stick loggers and the sofar_wifikit.yaml definitions.

I’d love to be able to switch the working mode between auto and TOU if possible, and icing on the cake would be to adjust the main TOU parameters. There’s several TOU ‘slots’ available, but I’d be happy just to be able to set the first one.

I think this must be possible, because sometimes Sofar enable the ability to change the settings from the app (although this facility seems to come and go).

I realise I could do this by switching to passive/bypass mode and using an ESP32 and mqtt, and that might be more flexible, but it’s also one more thing that might go wrong. In the spirit of keeping things simple I’d like to explore the option of changing these settings using this integration.

I’m out of my depth when it comes to the dev side, but I’d be happy to help test, if anyone is up for this.

Thank you.

[davidrapan]

Hi @PaulOckenden,

This integration does support configuration of your device so it should be doable! The only thing needed are the registers which does contain those values and then they can be added into said profile!

So if you are able to somehow get this information I'm more than happy to help!

[PaulOckenden]

Now working - the register was 0x1200.

Or 4608 in decimal.

Thanks.

[davidrapan]

Great. Do you want to add those registers as regular configurables? So they are directly exposed in the sensor list of the device?

[PaulOckenden]

Entirely up to you. I'm happy specifying the number, but if you want to take it to the next level that's fine by me!

[davidrapan]

So what profile it is and what are the possible values for the register then?

[PaulOckenden]

It's for sofar_wifikit.yaml, the register is 4608, the name is working_mode and the possible values are: 0 : auto 1 : time_of_use 2: timing 3: passive

It's read/write, but only works with write multiple.

[davidrapan]

      - name: Working Mode
        update_interval: 300
        platform: select
        rule: 1
        registers: [0x1200]
        options: ["Auto", "Time of Use", "Timing", "Passive"]
        lookup:
          - key: 0x0000
            value: "Auto"
          - key: 0x0001
            value: "Time of Use"
          - key: 0x0002
            value: "Timing"
          - key: 0x0003
            value: "Passive"

Try to add this into the profile and reload the integration. Report back if it works as expected. I'll add it if so. 😉

Little note: it won't show on the overview dashboard. You have to look into device detail page and you will find it in the configuration section.

[PaulOckenden]

Looks good to me!

[davidrapan]

Added in feat: Add zcs_azzurro-1ph-tl-v3.yaml

[PaulOckenden]

Sorry - on further testing (and also using write multiple) this doesn’t seem to work. Whatever you send always seems to set the mode to auto. I originally thought it worked because my inverter was in TOU mode and I tried switching it to Auto, which did work, but whatever you do always sets it to auto.

I’ll try to do some digging and see if I can set it to work manually, but for now I think the work mode switch should probably be suspended.

[davidrapan]

It's doing the same thing as when you set it from the service. 😉

So enable debug logging and try switching the selections and you will se exactly what is it doing, it's easy. 😉

[PaulOckenden]

The service doesn't work either (see the bit in brackets).

[davidrapan]

It does not matter. I simply told you how to find out what is happening. 😉

Also Solarman is not that reliable in general so you kinda can't expect 100% functionality in terms of controlling the device (sadly). It often timeouts cause stick refuses to process the request and so on. (I was lucky and it does works 100% for me with SG04LP3 so far)

[PaulOckenden]

This is the debug log of me switching from TOU to Auto and then back to TOU again.

It's not obviously to see the switch attempts amongst all the other stuff.

home-assistant_solarman_2024-09-02T21-08-05.486Z.log

It was for Battery 1 (1752627773).

[davidrapan]

Log says it was successful and if it did not change the value in the device I'm sorry but there is not much else we can do though... 😞

[PaulOckenden]

Yeah, that's what I thought, which is why I suggested suspending this function until it's possible to get to the bottom of the the issue. Thanks for your help.

[davidrapan]

I mean keeping the entity there can't cause any issues (+ some other users with your device have the possibility to also try it 😉) and if nothing else it at least serve purpose of displaying the value.

Two questions:

1. If you change the value to something else other than auto then and confirm trough the log that it was in fact successful. Does the value change in the HA into the auto on it's own during the next 5 minutes?
2. If you change the value in the device manually does it reflects in the HA again during the next 5 minutes?

[PaulOckenden]

OK.... Curiouser and curiouser....

It does appear to work for Auto and TOU, but not for timing.

And, it won't work if you happen to be in the work mode selection screen of the UI on the device. That's what confused me.

Hopefully if someone else has problems they will do a search and see this comment!