Victron to ESP using SerialProxy plugin

[Affinite]

Maybe just try to set the buffer size to 2048 to see if the number of checksum errors decrease as they still could be related to a full buffer.

Tried that, made no difference.

[Ath]

Another small update: ON and OFF values will be transformed into 1 and 0, to be usable as regular Values in the device configuration.

Available from this GH Actions run.

[Affinite]

I've tried your test-data, and used the same hardware configuration (GPIO-2 and a 256 byte buffer), and in my lab-environment ( ) it all works nicely:

Screenshot - 30-10-2024 , 20_41_19.png

This is tested using the latest code changes I made earlier today.

Also tried using SW Serial, but as expected, that's not working nicely, many checksum errors.

Thx, I think I need to test on an alternative device (just in case ...) - will report back in a few days.

[Affinite]

Is anyone else testing this (Victron not SerialProxy) plugin with a Victron device ?
It would be useful to know if you also get checksum errors or if your data is error-free (like Ath's)
Thanks

[Ath]

Is anyone else testing this (Victron not SerialProxy) plugin with a Victron device ?
It would be useful to know if you also get checksum errors or if your data is error-free (like Ath's)
Thanks

User Giorgino is also testing this, but only during the weekends, when he's working on his boat, AFAIK.
He posted screenshots in this same thread: https://letscontrolit.com/forum/viewtop ... =50#p71170 (using an older version of the plugin, though)

[Affinite]

Yes I was hoping he would respond but based on that screenshot and your tests it does look like the plugin is fine and something in my installation is the cause.

I now have 2 instances of P176 running on my ESP32C6 (with the same serial data source from my MPPT controller) but going into 2 different serial ports on the ESP32.
The ESP seems quite happy running 2 x P176 but I still get the checksum error (on both instances of P176) with pretty much every data packet sent.
Although I could ignore the checksum error it is like "having a stone in my shoe " so tomorrow I'm going to install P176 on my alternate (working) installation in my Motorhome.
That will be on a different ESP32 and a different Victron device (Victron Smart Shunt) connected directly together without a level shifter (the Victron Smart Shunt is 3.3V logic).
I'll report findings for the benefit of anyone following on behind.

[TD-er]

Is there some schematic online of the Victron you're using?
Or at least the wiring schematics of the serial port?
Sounds a bit like there might be something wrong with the ground, or maybe the Victron might even send negative voltages as the original 16450 from the IBM XT/AT did.
You did mention you have some level converter in use, but can it handle 12V level signals (assuming it might be really old-fashioned serial port levels..)

So please check the GND of your ESP is at the same level as the GND of the Victron before connecting both.
You could use some resistor between both GNDs and see if you measure any voltage over this resistor.
Value doesn't really matter, so anything between like 100 Ohm and 100k can be used, as long as any static voltage offset is eliminated.
Make sure both the Victron and the ESP are powered as you normally would when using.

[Affinite]

I don't think it's noise b it I'll test and report back

[Affinite]

OK, I installed P176 on a different ESP32 and different Victron device (Smart Shunt) which uses 3.3v logic so wired directly to the ESP serial input with no level converter.
This device is fitted in my Motorhome so its a different power supply. (12V-5V)
In other words a completely new set of hardware.
I am getting a nice stream of data from my Victron Shunt but I still get the checksum errors.

Ive noticed that the CS error messages in my log say "expected 0 ... and got ..."
Is that surprising? I'm not a coder but I would have thought that the expected CS value would vary and would rarely be 0

Based on the above, I dont think my CS errors are caused by noise or ground loops.
I can live with the few errors that Im getting so Im going to hope that another tester can report how their setup behaves wrt CS errors.

Here is my log from the new installation

Code: Select all

693437: WD   : Uptime 12  ConnectFailures 0 FreeMem 221224 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
693440: EVENT: Victron_Shunt#V=13.48
693453: EVENT: Victron_Shunt#I=0.68
693461: EVENT: Victron_Shunt#SOC=100
693468: EVENT: Victron_Shunt#VS=13.45
694396: Victron: Checksum error, expected 0 but got 118
694419: EVENT: Victron_Shunt#V=13.48
694425: EVENT: Victron_Shunt#I=0.67
694431: EVENT: Victron_Shunt#SOC=100
694438: EVENT: Victron_Shunt#VS=13.45
695312: EVENT: Victron_Shunt#V=13.48
695321: EVENT: Victron_Shunt#I=0.66
695329: EVENT: Victron_Shunt#SOC=100
695336: EVENT: Victron_Shunt#VS=13.45
695714: Victron: Checksum error, expected 0 but got 55
696307: EVENT: Victron_Shunt#V=13.48
696316: EVENT: Victron_Shunt#I=0.66
696321: EVENT: Victron_Shunt#SOC=100
696327: EVENT: Victron_Shunt#VS=13.45
697214: Victron: Checksum error, expected 0 but got 118
697307: EVENT: Victron_Shunt#V=13.48
697312: EVENT: Victron_Shunt#I=0.67
697320: EVENT: Victron_Shunt#SOC=100
697326: EVENT: Victron_Shunt#VS=13.45
698311: EVENT: Victron_Shunt#V=13.48
698319: EVENT: Victron_Shunt#I=0.66
698327: EVENT: Victron_Shunt#SOC=100
698332: EVENT: Victron_Shunt#VS=13.45
698714: Victron: Checksum error, expected 0 but got 55
699310: EVENT: Victron_Shunt#V=13.48
699319: EVENT: Victron_Shunt#I=0.66
699328: EVENT: Victron_Shunt#SOC=100
699335: EVENT: Victron_Shunt#VS=13.45
700234: Victron: Checksum error, expected 0 but got 118
700309: EVENT: Victron_Shunt#V=13.48
700317: EVENT: Victron_Shunt#I=0.67
700325: EVENT: Victron_Shunt#SOC=100
700331: EVENT: Victron_Shunt#VS=13.45
701308: EVENT: Victron_Shunt#V=13.48
701315: EVENT: Victron_Shunt#I=0.69
701321: EVENT: Victron_Shunt#SOC=100
701326: EVENT: Victron_Shunt#VS=13.45
701910: Victron: Checksum error, expected 0 but got 55
702313: EVENT: Victron_Shunt#V=13.48
702319: EVENT: Victron_Shunt#I=0.69
702326: EVENT: Victron_Shunt#SOC=100
702333: EVENT: Victron_Shunt#VS=13.45
703367: Victron: Checksum error, expected 0 but got 118
703384: EVENT: Victron_Shunt#V=13.48
703393: EVENT: Victron_Shunt#I=0.67
703403: EVENT: Victron_Shunt#SOC=100
703411: EVENT: Victron_Shunt#VS=13.45
704311: EVENT: Victron_Shunt#V=13.48
704316: EVENT: Victron_Shunt#I=0.66
704322: EVENT: Victron_Shunt#SOC=100
704329: EVENT: Victron_Shunt#VS=13.45
704745: Victron: Checksum error, expected 0 but got 55
705308: EVENT: Victron_Shunt#V=13.48
705316: EVENT: Victron_Shunt#I=0.66
705322: EVENT: Victron_Shunt#SOC=100
705327: EVENT: Victron_Shunt#VS=13.45
706331: Victron: Checksum error, expected 0 but got 118
706348: EVENT: Victron_Shunt#V=13.48
706356: EVENT: Victron_Shunt#I=0.66
706361: EVENT: Victron_Shunt#SOC=100
706368: EVENT: Victron_Shunt#VS=13.45
707312: EVENT: Victron_Shunt#V=13.48
707318: EVENT: Victron_Shunt#I=0.65
707324: EVENT: Victron_Shunt#SOC=100
707331: EVENT: Victron_Shunt#VS=13.45
707770: Victron: Checksum error, expected 0 but got 55
708315: EVENT: Victron_Shunt#V=13.48
708321: EVENT: Victron_Shunt#I=0.65
708332: EVENT: Victron_Shunt#SOC=100
708338: EVENT: Victron_Shunt#VS=13.45
709270: Victron: Checksum error, expected 0 but got 118
709443: EVENT: Victron_Shunt#V=13.48
709459: EVENT: Victron_Shunt#I=0.66
709468: EVENT: Victron_Shunt#SOC=100
709474: EVENT: Victron_Shunt#VS=13.45
710313: EVENT: Victron_Shunt#V=13.48
710324: EVENT: Victron_Shunt#I=0.65
710329: EVENT: Victron_Shunt#SOC=100
710337: EVENT: Victron_Shunt#VS=13.45
710777: Victron: Checksum error, expected 0 but got 55
711319: EVENT: Victron_Shunt#V=13.48
711325: EVENT: Victron_Shunt#I=0.65
711333: EVENT: Victron_Shunt#SOC=100
711340: EVENT: Victron_Shunt#VS=13.45
712294: Victron: Checksum error, expected 0 but got 118
712311: EVENT: Victron_Shunt#V=13.48
712320: EVENT: Victron_Shunt#I=0.66
712329: EVENT: Victron_Shunt#SOC=100
712336: EVENT: Victron_Shunt#VS=13.45

[Ath]

The simple checksum calculation used, is a modulo 256 addition of all characters received, and the checksum byte just adds up to fill the last gap to reach that 256. So the expected checksum result is always 0.

But that doesn't exclude an error in my implementation

[Affinite]

The simple checksum calculation used, is a modulo 256 addition of all characters received, and the checksum byte just adds up to fill the last gap to reach that 256. So the expected checksum result is always 0.

But that doesn't exclude an error in my implementation

Thanks for the explanation Ton.
I'll experiment a little more but probably best to wait for feedback from other testers.

[Ath]

I have tackled the Checksum validation issue. Was ignoring the first line of data after a valid checksum and also have to drop any data of the initially received (possibly partial) packet when checksum validation is used.

Should be good for testing, download from this GH Actions run

[giorgino]

I'm sorry guys, no works onboard this weekend. I've got this screenshot in my first tries with the second version of the plugin, and some checksum error appeared.

Immagine 2024-11-03 183428.jpg (278.46 KiB) Viewed 3247 times

if this could be useful to you.....

[Affinite]

Tested this evening on my ESP32 - P176 now works great with no more checksum errors.
Edit:Also now tested on ESP32C6-16M and Victron Smart MPPT charger with a level shifter to convert 5V (Victron MPPT) to 3.3V (ESP) logic.

Thanks Ton

[Ath]

YAY! Great

Thanks for the confirmation

[Affinite]

Ath,
Further testing of P176 Victron Serial
Is there a way to distinguish between a task value that has not changed because the value sent by the Victron sender has remained constant and a task value that has not changed because the serial data received has stopped.
I've noticed that if the serial data received by the plugin stops, the task value persists at the last value received from the Victron sender.
In my implementation, I wake up the ESP from DeepSleep, read the task values I need, publish them to MQTT and then go back to sleep.
The problem is that if the Victron sender has failed, I don't notice it as I simply get the last value that the plugin received, so when monitoring a Victron Smart Shunt which sends a battery voltage "V" of 12.8V I wont notice if the Victron serial stream fails (broken cable perhaps) but the ESP keeps sending 12.8V and my battery slowly discharges.

Is there a way to overcome this in rules or do we need some sort of timeout function in the plugin ?

[Ath]

Hmm, that's a situation I've not accounted for, and have to think about how to resolve.
Haven't been testing with a real device, so it's a bit hard to see the 'real life' situations.
According to the documentation, a packet (or maybe more) should/could be sent once a second, so 'outdated' data wasn't what I would expect.

I can keep a 'last received' time, but we might have to agree on a duration when a timeout occurs on that.

Still thinking...

[TD-er]

... of add virtual taskvalues like "success" and "failed" (to be accessed via [victron#success] for example, for a task called "victron")
This can be useful for quite a lot more plugins.

This way you can keep track of the connection count and stability via rules.
Just compare it with a previous value you store in a variable.
If (only) the success counter increases, then it is OK

[Affinite]

Hmm, that's a situation I've not accounted for, and have to think about how to resolve.
Haven't been testing with a real device, so it's a bit hard to see the 'real life' situations.
According to the documentation, a packet (or maybe more) should/could be sent once a second, so 'outdated' data wasn't what I would expect.

I can keep a 'last received' time, but we might have to agree on a duration when a timeout occurs on that.

Still thinking...

As you say, the Victron sender sends a data packet every second so I was thinking that if no packet is received for (user defined) seconds (say 10), have an option to reset all task values to NaN or allow last received task values to persist

[bonti69]

I'm new on ESP32.
ESP32 has more hardware UART. The Victron plugin will run on multiple victron devices, on the same ESP32 board? Or will flood the CPU?

[Affinite]

Scheme-it-export-Kim-ESP32-2024-11-16-08-25.png (48.88 KiB) Viewed 2828 times

I'm new on ESP32.
ESP32 has more hardware UART. The Victron plugin will run on multiple victron devices, on the same ESP32 board? Or will flood the CPU?

Ath or TD-er will know how many serial devices the serial engine of ESPEasy can cope with but FWIW my setup works just fine with 2 Victron devices.
(Shunt and MPPT)

[TD-er]

ESP32 (classic) does have 3 hardware serial ports.
So if you disable the ESPEasy console, you can handle upto 3 of these tasks.
I don't see why ESPEasy cannot handle this as it isn't a really hard protocol to decode and the hardware serial ports do all the time critical work for you.
So you essentially have to read like 10 'packets' per second from 3 devices, which isn't that much.
A GPS receiver does generate more data.

It would be too much to do all in rules, but now we have a separate plugin for it, I don't see any limitation here.

You could also add those I2C to UART chips and add upto 2 serial ports per I2C-UART bridge chips.

Usually these kind of 'industrial' modules do communicate over RS485 using the modbus protocol.
This way you can add upto 31 devices per serial port. I don't know why this Victron isn't using Modbus, if it is not uncommon to have multiple at the same location.

[giorgino]

today a new issue on my system: I've finally connected the second Victron device. After the connection the signals from the first stops working
Then no other signals (also from the first)

@affinite : do you connect only gnd and tx or +5v too?
I've only gnd and tx

[TD-er]

Is the baudrate also correct?

[Affinite]

Ground, tx and 5v to the level shifter from the MPPT charge controller- my connections to my Victron devices are exactly as my diagram shows.
FWIW I could not get data into my ESP using Rxd on GPIO3 but I didnt get rubbish like you, I just didnt get any data so I swapped to an alternate GPIO pin and it works fine with 2 channels.
Do your cables run anwhere with electrical noise (engine bay perhaps) ?
My shunt cable is just 2 cores and only 20cm long. The other cable is 2 cores in a screened cable with screen connected to ground and level shifter in-line. This one is approx 100cm.

[giorgino]

same baud rate, same configuration, one at interval 15, the other interval17
I have never connected the 5V of BMV (ad it's working from one year with two wires non shielded), I heard on some forum to leave it disconnected

100cm non shielded cable in a clean way (passing throw holes nearh 12V battery, sometimes the 220 charger)

[TD-er]

Just a generic warning, when connecting signals from a different source which may have a completely different ground potential, you may risk frying the GPIO pins as the potential can be quite different if both grounds aren't equal.
That's also why for industrial use cases they use RS485, which is a differential signal, which is easier to deal with when experiencing ground potential differences.

[Ath]

I've added a setting to the plugin to only generate events and send data to Controllers when new data has been received since the last Interval/TaskRun.

Binaries available from this GH Actions run. (An independent extension to the "[Victron#updated]" value that can be polled from rules.)
Please report your findings with this new feature.

[Affinite]

Just a thought ...
Do you have any other serial plugins installed ?
I only have 3 tasks configured.
2 x P176 Victron plugin and 1 x ds18b20 temp sensor

[Affinite]

I've added a setting to the plugin to only generate events and send data to Controllers when new data has been received since the last Interval/TaskRun.

Binaries available from this GH Actions run. (An independent extension to the "[Victron#updated]" value that can be polled from rules.)
Please report your findings with this new feature.

Ath - I meant to let you know that the Victron State of Operation "CS" (should be numeric 0-5) field does not come out of the plugin as a numeric Task Value.
The value is appended to the topic and the Value is sent a a string "".
I've just filtered and sorted it in Node-Red when I receive it but might be worth looking at if you have the "hood up" on P176

I cant access the ESPEasy log right now but this is how I receive in Node-Red
24/11/2024, 13:29:09node: debug 7
Kimberley/chargers.MPPT.state3 : msg.payload : string[0]
""

[Ath]

Ath - I meant to let you know that the Victron State of Operation "CS" (should be numeric 0-5) field does not come out of the plugin as a numeric Task Value.
The value is appended to the topic and the Value is sent a a string "".
I've just filtered and sorted it in Node-Red when I receive it but might be worth looking at if you have the "hood up" on P176

I cant access the ESPEasy log right now but this is how I receive in Node-Red
24/11/2024, 13:29:09node: debug 7
Kimberley/chargers.MPPT.state3 : msg.payload : string[0]
""

Can you show the raw data from the Config page of the plugin? (In a previous post it shows CS 0)
The CS value is treated exactly the same as any other value, when a numeric value can be parsed it will return that, else it will return 0 when set as one of the values, or return the raw string value when retrieved via GetConfig (not selected as a Value, and retrieved in Rules using [<TaskName>#CS])

[giorgino]

yes I have more serial:
gpio 16: victron MPTT
gpio 17: victron BMV712
gpio 19: GPS neo
the display NEXTION (tx and rx) arrive throw I2L software serial

the two ground of the two victron-ve is connected at the general GND

[TD-er]

Which ESP32 are you using?
For ESP32 (classic) GPIO 16 and 17 are not the best choice as those are also used for PSRAM and thus can sometimes show unexpected behavior.
See: https://espeasy.readthedocs.io/en/lates ... e-on-esp32


Also why do you need software serial?
You only should use SW serial as a last resort as its frequent interrupt handling affects all other code running on the ESP.

[Affinite]

Ath - I meant to let you know that the Victron State of Operation "CS" (should be numeric 0-5) field does not come out of the plugin as a numeric Task Value.
The value is appended to the topic and the Value is sent a a string "".
I've just filtered and sorted it in Node-Red when I receive it but might be worth looking at if you have the "hood up" on P176

I cant access the ESPEasy log right now but this is how I receive in Node-Red
24/11/2024, 13:29:09node: debug 7
Kimberley/chargers.MPPT.state3 : msg.payload : string[0]
""

Can you show the raw data from the Config page of the plugin? (In a previous post it shows CS 0)
The CS value is treated exactly the same as any other value, when a numeric value can be parsed it will return that, else it will return 0 when set as one of the values, or return the raw string value when retrieved via GetConfig (not selected as a Value, and retrieved in Rules using [<TaskName>#CS])

Ton,
sorry to waste your time on my CS problem.
It was my mistake ... I had a missing "," in my Publish statement in Rules
Thx

[giorgino]

yes I have more serial:
gpio 16: victron MPTT
gpio 17: victron BMV712
gpio 19: GPS neo
the display NEXTION (tx and rx) arrive throw I2L software serial

the two ground of the two victron-ve is connected at the general GND

I'm using ESP32-S3 and I need at least 4 serial
Do you think it' better to leave 16 ant 17 free anyway ?

[TD-er]

The S3 has different pins connected.
See: https://espeasy.readthedocs.io/en/lates ... n-esp32-s3
GPIO-19 is connected to one of the USB pins, so that's a bad choice as it removes the option to access ESPEasy via USB for access to the console or flashing if you want to use the 3 other HW serial ports the S3 offers.

If you really need to use SW serial, then please use it for some device which isn't that 'chatty' like GPS.
The GPS will send nearly continuously at a relative low baudrate, so it will constantly generate interrupts which does affect other time-critical code on the ESP.

SW serial should really be considered as the last resort on ESP32-xx as it really is slowing everything down and also corrupts data every now and then.

[giorgino]

yes I have more serial:
gpio 16: victron MPTT
gpio 17: victron BMV712
gpio 19: GPS neo
the display NEXTION (tx and rx) arrive throw I2L software serial

the two ground of the two victron-ve is connected at the general GND

mmmh I think I got a mistake, in effect on my ESP32-S3 i have:
HW SERIAL 0
HW SERIAL 1
HW SERIAL 2
SW SERIAL
USBHWCDC
I2C SERIAL

So, leaving alone the SW SERIAL I will set my config as follow:
gpio 16: victron MPTT -->> HW SERIAL 0
gpio 17: victron BMV712 -->> HW SERIAL 1
gpio 39: GPS neo -->> HW SERIAL 2
gpio 10 and gpio 11 : from I2C serial (I'm using the chip WCMCU-752)

Now remain the doubt about connecting two ve-direct gnd togheter

[TD-er]

Why not connect both Victrons to the I2C serial adapter to port A and B?
Those do not such large messages, so they do match well to the 64 byte FIFO buffer of the I2C serial adapter.
You may see a few more 'checksum errors' though as the data must be fetched using software from it as long as you're not missing the same messages over and over again.
Otherwise we might need to add an extra buffer layer inbetween.

If grounding is an issue, you can also look into optocouplers or i-coupler chips.
Since you only need to receive data, I think an optocoupler is the easiest as long as you don't need high baudrates (not all optocouplers can handle over 10's of kHz)

One of the first hits on duckduckgo for "optocoupler serial":
https://arduino.stackexchange.com/quest ... ptocoupler

[giorgino]

the victron baudrate is 19200. Could it be a problem?

[TD-er]

Most optocouplers can probably handle it, but you might want to tweak it a bit to reduce capacitance in the connections to/from the LED and maybe reduce the resistor in front of the LED a bit.
If you can find information like 'rise time' or 'propagation delay' in the datasheet of the optocoupler you like to buy, you should take one which is in the order of 10 - 20 usec or lower.
The LED in the optocoupler will show some 'after glow' when turning off.
This will probably be the most problematic in the switching speed of optocouplers.

High-speed applications do use some complex switching using some coil to create some reverse feed to turn the LED off as fast as possible.
That's probably one of the tweaks used in "high speed" optocouplers.

However I think that 20-ish kHz would be doable with most optocouplers.

Found some at Ali for next to nothing which are rated upto 10 Mbps: https://www.aliexpress.com/item/1005006809865523.html

[Affinite]

KISS
I cant help thinking that an ESP32 dedicated to the Victrons (and perhaps your GPS) is the way to go.
Yes, you have 2 x ESP32 with corresponding increase in power requirement but when you are away from the boat you dont need real-time so you can DeepSleep the ESP for long periods and just send hourly/daily updates so your power drain will be pretty small.
On my MH ( and on my boat before I sold it ) I have a 100W solar panel which keeps battery topped up and the ESP is waking up from its sleep every 10 minutes to send me an update.
Only time I have a problem is when the solar panel gets covered in snow - but Im guessing you wont have that problem

[bonti69]

I've added a setting to the plugin to only generate events and send data to Controllers when new data has been received since the last Interval/TaskRun.

Binaries available from this GH Actions run. (An independent extension to the "[Victron#updated]" value that can be polled from rules.)
Please report your findings with this new feature.

Sorry, which build should be uploaded to ESP32 - that includes Victron P176 communication device ?

[Affinite]

I believe you need

ESP_Easy_mega_20241124_energy_ESP32_4M316k.bin for OTA update or
ESP_Easy_mega_20241124_energy_ESP32_4M316k.factory.bin for serial update

[Ath]

Yep, it's in the Energy builds for 4MB ESP32 units and the MAX builds for ESP32 models with 8MB or 16MB flash.

[bonti69]

Thanks,
Only 4 values ?

Screenshot 2024-11-26 at 13-04-10 ESP32.png (40.63 KiB) Viewed 1526 times

Voltage, current, power of battery or panel?

[bonti69]

GPIO1/txd and GPIO3/rxd HW serial 0 = native serial of ESP32
GPIO17/TX2 and GPIO16/RX2 HW serial 1
HW serial 2 can be defined on any GPIO available?

doc-esp32-pinout-reference-wroom-devkit_png_80.jpg (108.72 KiB) Viewed 1511 times

Surprise : gpio pins are not 5V tolerant !

[Affinite]

Thanks,
Only 4 values ?
Screenshot 2024-11-26 at 13-04-10 ESP32.png
Voltage, current, power of battery or panel?

No, if you look at the plugin device screen it shows a panel with all the Victron values that are being received.
You can then read them in rules using Taskname#Value
see my rules below as an example

Code: Select all

//see rules set 2 for old rules

on mqtt#connected do
  LoopTimerSet,1,600 //Last number is seconds for send delay
  asyncevent,sendvaluestomqtt
endon

on sendvaluestomqtt do
  publish,Kimberley/batteries.house.voltage,[Victron_Shunt#V]     // House Battery Voltage. Maybe confusing as this is avaiable from MPPT and Shunt  
  publish,Kimberley/batteries.start.voltage,[Victron_Shunt#VS]      // Start Battery Voltage
  publish,Kimberley/batteries.house.current,[Victron_Shunt#I]       // House current
  publish,Kimberley/batteries.SOC,[Victron_Shunt#SOC]              // House Battery State of Charge
  publish,Kimberley/temperature.inside,[temperature#inside]
  publish,Kimberley/temperature.outside,[temperature#outside]
  publish,Kimberley/solarpanel.voltage,[Victron_MPPT#VPV] // PV Panel Voltage
  publish,Kimberley/solarpanel.current,[Victron_MPPT#I]             // PV Panel Current
  publish,Kimberley/solarpanel.power,[Victron_MPPT#PPV] // PV Panel Power
  publish,Kimberley/chargers.MPPT.state[Victron_MPPT#CS]     // MPTT State  0-OFF 1-n/a  2-Fault 3-Bulk 4-Absorption 5-Float
endon

On Rules#Timer=1 do
 asyncevent,sendvaluestomqtt
endon

Edit: Bit embarrassing but Ive just realized I left a LoopTimerSet command in my rules which is unnecessary.
Its untidy but ignored as Ive set (in Config) the ESP to Deepsleep for 10 minutes after 30 seconds awake.
On next tidy-up I'll put the sleep cycle into rules so as to reduce awake time to the minimum required to publish values

[Affinite]

GPIO1/txd and GPIO3/rxd HW serial 0 = native serial of ESP32
GPIO17/TX2 and GPIO16/RX2 HW serial 1
HW serial 2 can be defined on any GPIO available?

doc-esp32-pinout-reference-wroom-devkit_png_80.jpg

Surprise : gpio pins are not 5V tolerant !

see post #121 - this setup works for me

[bonti69]

HW serial 2 can be defined on any GPIO available?

see post #121 - this setup works for me

Short answer is yes, HW serial2 is user defined
I figured must have some rules and a dummy device with values extracted from victron.
On the dashboard what the values V,I,P means? My device is not connected with any victron yet, just playing around

Screenshot 2024-11-26 at 14-35-38 ESP32.png (70.08 KiB) Viewed 1486 times

[Affinite]

Have a look at the V.E.Direct protocol specification document on the Victron website. (Very useful)
www.victronenergy.com/support-and-downl ... nformation
In it you will see a description of all the data fields transmitted by Victron devices.

V is the field for Main battery Voltage
I is for Current
P is for Power and
ERR is for Error