Slave or Master?

[Spookster]

Hey, just trying to work through connection issues for a new build on a smile5. Definitions set to :

define INVERTER_SMILE5

I have a working wemos mini and max3485, software loaded, it connects to wireless etc Display shows A2M *WM

Currently I have a bad crc UR/HB and Im trying to trouble shoot it.

Like you, I have blue + blue/white providing 4v, other wires nothing. Ive swapped these 2 around, and it doesnt start with blue connected to A

When I checked the Alpha unit, MODBUS was off. Ive turned it on. Theres also an option for master / slave. Ive tried both, but assume I would use slave.

You also suggest : Make sure the Slave IDs match. Alpha systems use 0x55 by default but if you have changed it on an inverter with an on device interface, change the appropriate line in Definitions.h as documented above.

I havent changed anything, but how would I check this value if required?

D4 and D5 leds flash on the 385

There is continuity between all connections (as much as I can tell)

Any words of wisdom? Thanks!

[dxoverdy]

Frustrating I can imagine! Some points:

Blue white definitely A.

The Alpha should be a slave. For some reason I thought the address could be changed in the on display settings.

Can you check continuity between pins in both yellow circles? And for A and B at this point have you got 4V?

Can you check for continuity between pins 6 and 7 on the D1 and ensure that 7 is RX

There is a little script called slave address finder which will cycle through every possible slave address and return on the screen or mqtt the slave address, but that definitely assumes no hardware issues first!

If you can send more pics of the entire soldering/wiring setup that will help, as will a video of the 3845 flashing in dim light up close 👍

Regards Dan

On Sat, 20 May 2023 at 02:54, Spookster @.***> wrote:

Hey, just trying to work through connection issues for a new build on a smile5. Definitions set to :

define INVERTER_SMILE5

I have a working wemos mini and max3485, software loaded, it connects to wireless etc Display shows A2M *WM

Currently I have a bad crc UR/HB and Im trying to trouble shoot it.

Like you, I have blue + blue/white providing 4v, other wires nothing. Ive swapped these 2 around, and it doesnt start with blue connected to A

When I checked the Alpha unit, MODBUS was off. Ive turned it on. Theres also an option for master / slave. Ive tried both, but assume I would use slave.

You also suggest : Make sure the Slave IDs match. Alpha systems use 0x55 by default but if you have changed it on an inverter with an on device interface, change the appropriate line in Definitions.h as documented above.

I havent changed anything, but how would I check this value if required?

[image: image] https://user-images.githubusercontent.com/982535/239662161-eb4256f7-5d03-46b3-9e26-1a22e50aa321.png D4 and D5 leds flash on the 385

There is continuity between all connections (as much as I can tell)

Any words of wisdom? Thanks!

— Reply to this email directly, view it on GitHub https://github.com/dxoverdy/Alpha2MQTT/issues/10, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZC7OYNMPRNZOFBT6ILJAP3XHAP6PANCNFSM6AAAAAAYINLYZM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[dxoverdy]

bah, email attachments don’t work

[Spookster]

Blue white definitely A. Yes

The Alpha should be a slave. Yes, it is set

Can you check continuity between pins in both yellow circles? The 4 pin holes and wiring back to the d1 have continuity, as do the a/b terminals (pardon the tack soldering ; )

And for A and B at this point have you got 4V? Yes, it varies between 3.6-4.3

Can you check for continuity between pins 6 and 7 on the D1 and ensure that 7 is RX There is continuity and using MISO(6) MOSI(7) and 3v3

[dxoverdy]

If both leds are flashing on the 3485 then let’s think out loud…

Only one LED should flash at a time, both flashing at the same time would indicate a short between mosi and miso but if the flashes are alternate that indicates your alpha is getting the request, processing it and sending something back but for some reason it’s not getting it’s way back to the RX (d7/mosi) on the d1 mini.

It can be confusing but when the d1 mini transmits, the RX led on the 3485 will flash, when the 3485 is sending the result back to the d1 mini the tx LED will flash, so in effect the LEDs refer to the TTL side, not the rs485 side.

On Sat, 20 May 2023 at 05:31, Spookster @.***> wrote:

Blue white definitely A. Yes

The Alpha should be a slave. Yes, it is set

Can you check continuity between pins in both yellow circles? The 4 pin holes and wiring back to the d1 have continuity, as do the a/b terminals [image: image] https://user-images.githubusercontent.com/982535/239667221-e23d3a69-d420-4839-8e09-e2192121bae2.png (pardon the tack soldering ; )

And for A and B at this point have you got 4V? Yes, it varies between 3.6-4.3

Can you check for continuity between pins 6 and 7 on the D1 and ensure that 7 is RX There is continuity and using MISO(6) MOSI(7) and 3v3

[image: image] https://user-images.githubusercontent.com/982535/239667195-caa236e6-f51a-464d-8516-4fa77281e201.png

— Reply to this email directly, view it on GitHub https://github.com/dxoverdy/Alpha2MQTT/issues/10#issuecomment-1555504201, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZC7OYLPL4J7O4XFPCUDSMDXHBCLVANCNFSM6AAAAAAYINLYZM . You are receiving this because you commented.Message ID: @.***>

[dxoverdy]

Flashing behaviour vids I’ve just uploaded for reference. Although it’s hard to discern, the rx tx LEDs alternate quickly because tx and rx aren’t concurrent.

https://youtu.be/vr_lAvNwqhU

https://youtu.be/SKvm9r_2P_U

[Spookster]

I'll have another look in the morning, but fairly confident they are flashing independently , so I guess theres still possibly some disconnect between the d1 and the 485 but obviously connected to data

[dxoverdy]

That's it... if flashing independently I think you can be quite confident that a message is getting out, that the Alpha is processing it and sending back... and there's just a bit of an issue with the RX element. If nothing comes back from the Inverter (ala no flash) then it's open to a whole host of reasons why. The Alpha system just doesn't respond if a message is incorrect, which is irritating because it's no different to when unplugged which makes debugging.... interesting nonetheless.

Sleep well.

On Sat, 20 May 2023 at 08:42, Spookster @.***> wrote:

I'll have another look in the morning, but fairly confident they are flashing independently , so I guess theres still possibly some disconnect between the d1 and the 485 but obviously connected to data

— Reply to this email directly, view it on GitHub https://github.com/dxoverdy/Alpha2MQTT/issues/10#issuecomment-1555809124, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZC7OYI4SWIOMVR326JE4YTXHBYUVANCNFSM6AAAAAAYINLYZM . You are receiving this because you commented.Message ID: @.***>

[Spookster]

Heres a startup vid. Swapped back to a breadboard and different D1, same result it seems. Hmmmm https://youtu.be/IcMiEl4qNeI

[Spookster]

And with D6 disconnected : https://youtu.be/7XqfhLH2aDw

I swapped out the screen and resoldered too, just in case there were any shorts....

[dxoverdy]

D7 which is output from the wemos, if disconnected, should result in zero LED flashes. I've uploaded a video here (Youtube insists it is a short not a proper video :( ), https://www.youtube.com/shorts/q75st04LnK8, it shows D7 connected and no Alpha connected. You can see just the RX led flashes each time the wemos pings a message. Nothing comes back because there is no Alpha so the TX pin never flashes. Disconnecting D7 mid-way through the video demonstrates the RS485 stops getting pings from the wemos and so lies dormant until I plug it back in.

What's the behaviour of yours if you unplug the alpha and record D7 connected for a while, D7 disconnected for a while and D7 reconnected? Dan

On Sat, 20 May 2023 at 23:27, Spookster @.***> wrote:

And with D7 disconnected : https://youtu.be/7XqfhLH2aDw

— Reply to this email directly, view it on GitHub https://github.com/dxoverdy/Alpha2MQTT/issues/10#issuecomment-1556030993, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZC7OYOQ27FVE4PA5R2O6Z3XHFAO3ANCNFSM6AAAAAAYINLYZM . You are receiving this because you commented.Message ID: @.***>

[dxoverdy]

Further, on closer look, you've unplugged D6, so the wemos is able to ping messages via the wemos D7 tx pin (so 485 rx LED flashes) and it looks like the 485 pings a message back via the 485 tx pin (tx led flashes) but the wemos d6 RX pin is disconnected and so nothing happens.

[image: image.png]

On Sun, 21 May 2023 at 07:41, Daniel Young @.***> wrote:

D7 which is output from the wemos, if disconnected, should result in zero LED flashes. I've uploaded a video here (Youtube insists it is a short not a proper video :( ), https://www.youtube.com/shorts/q75st04LnK8, it shows D7 connected and no Alpha connected. You can see just the RX led flashes each time the wemos pings a message. Nothing comes back because there is no Alpha so the TX pin never flashes. Disconnecting D7 mid-way through the video demonstrates the RS485 stops getting pings from the wemos and so lies dormant until I plug it back in.

What's the behaviour of yours if you unplug the alpha and record D7 connected for a while, D7 disconnected for a while and D7 reconnected? Dan

On Sat, 20 May 2023 at 23:27, Spookster @.***> wrote:

And with D7 disconnected : https://youtu.be/7XqfhLH2aDw

— Reply to this email directly, view it on GitHub https://github.com/dxoverdy/Alpha2MQTT/issues/10#issuecomment-1556030993, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZC7OYOQ27FVE4PA5R2O6Z3XHFAO3ANCNFSM6AAAAAAYINLYZM . You are receiving this because you commented.Message ID: @.***>

[dxoverdy]

ala

[dxoverdy]

The email I got said unplugged D7, I think you've edited to D6. Ok, so, as I say, nothing would flash differently in the case of D6 disconnected, it's just the wemos wouldn't get any message back to do anything.

D7 would be interesting, if you could do that demonstration as I wrote about above.

[dxoverdy]

I've published a new version - v1.20. Download the code, plumb in your WiFi and MQTT details and uncomment line 961 in Definitions.h (DEBUG_OUTPUT_TX_RX) and optionally 959, (DEBUG).

If you then use the serial monitor in the Arduino IDE, you will see the actual transmitted and received bytes. This outputs the absolute raw data sent and received. In the case of receive, I was curious as to whether your Wemos is receiving anything and if it is corrupted. If you are getting some Rx bytes back and they aren't passing the CRC checks, that would also yield a BAD-CRC-UR, the same as nothing received at all. If you could send me some of the Tx and Rx lines returned back we can then take next steps.

When plugged in.

When unplugged.

[Spookster]

Will do, I'll let you know how I get on. I'll make it tomorrow's project. Thanks for the help

[Spookster]

D7 would be interesting, if you could do that demonstration as I wrote about above.

Correct, it operates as you expect. Pulling D7 results in both leds not flashing - no signal from the D1 to the Max

Apologies for the D6/D7 edit further up, I thought I got it in time ;) I initially wrote D7 and then realized I pulled D6.

[Spookster]

This is with Alpha plugged in:

08:57:10.578 -> Timeout waiting for RS485 response.  Likely no more data coming.
08:57:10.648 -> Rx: Nothing
08:57:10.648 -> Tx: 55 03 08 86 00 01 6A 57
08:57:10.989 -> Timeout waiting for RS485 response.  Likely no more data coming.
08:57:11.059 -> Rx: Nothing
08:57:11.059 -> Tx: 55 03 08 87 00 02 7B 96
08:57:11.399 -> Timeout waiting for RS485 response.  Likely no more data coming.
08:57:11.466 -> Rx: Nothing
08:57:11.466 -> Tx: 55 03 04 1F 00 02 F9 29
08:57:11.499 -> Rx: 55 03 04 00 00 00 A1 2E 4E
08:57:11.531 -> Tx: 55 03 04 23 00 02 39 25
08:57:11.614 -> Rx: 55 03 04 00 00 00 80 EE 56
08:57:11.660 -> Tx: 55 03 04 27 00 02 78 E4
08:57:11.739 -> Rx: 55 03 04 00 00 00 00 EF F6

and without:

09:00:57.296 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:00:57.365 -> Rx: Nothing
09:00:57.365 -> Tx: 55 03 08 87 00 02 7B 96
09:00:57.706 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:00:57.775 -> Rx: Nothing
09:00:57.775 -> Tx: 55 03 04 1F 00 02 F9 29
09:00:58.114 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:00:58.185 -> Rx: Nothing
09:00:58.185 -> Tx: 55 03 04 23 00 02 39 25
09:00:58.526 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:00:58.595 -> Rx: Nothing
09:00:58.595 -> Tx: 55 03 04 27 00 02 78 E4
09:00:58.935 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:00:59.005 -> Rx: Nothing
09:00:59.005 -> Tx: 55 03 04 2B 00 02 B8 E7
09:00:59.335 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:00:59.412 -> Rx: Nothing
09:00:59.412 -> Tx: 55 03 04 2F 00 02 F9 26
09:00:59.756 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:00:59.825 -> Rx: Nothing
09:00:59.825 -> Tx: 55 03 04 33 00 02 38 E0
09:01:00.166 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:01:00.234 -> Rx: Nothing
09:01:00.234 -> Tx: 55 03 00 A1 00 02 98 3D
09:01:00.576 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:01:00.643 -> Rx: Nothing

[Spookster]

With a full debug, alpha disconnected:

09:09:31.762 -> Rx: Nothing
09:09:31.762 -> noResponse
09:09:31.840 -> Tx: 55 03 01 02 00 01 29 E2
09:09:32.241 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:09:32.319 -> Timed Out (inByteNumZeroIndexed): 0
09:09:32.353 -> Timed Out (gotSlaveID): 0
09:09:32.386 -> Timed Out (gotFunctionCode): 0
09:09:32.420 -> Timed Out (resp->functionCode): 0
09:09:32.454 -> Timed Out (gotData): 0
09:09:32.454 -> Timed Out (resp->dataSize): 0
09:09:32.486 -> Rx: Nothing
09:09:32.519 -> Failed to addStateInfo for: 258, Result was: 4
09:09:32.553 -> Tx: 55 03 01 26 00 01 69 E9
09:09:32.868 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:09:32.951 -> Timed Out (inByteNumZeroIndexed): 0
09:09:32.985 -> Timed Out (gotSlaveID): 0
09:09:33.019 -> Timed Out (gotFunctionCode): 0
09:09:33.052 -> Timed Out (resp->functionCode): 0
09:09:33.085 -> Timed Out (gotData): 0
09:09:33.085 -> Timed Out (resp->dataSize): 0
09:09:33.118 -> Rx: Nothing

And alpha connected:

09:12:44.369 -> Rx: 55 03 04 A8 5C 00 02 8E 45
09:12:44.400 -> Tx: 55 03 04 33 00 02 38 E0
09:12:44.477 -> Rx: 55 03 04 00 00 00 00 EF F6
09:12:44.523 -> Tx: 55 03 00 A1 00 02 98 3D
09:12:44.617 -> Rx: 55 03 04 00 00 00 00 EF F6
09:12:44.695 -> Tx: 55 03 04 1F 00 02 F9 29
09:12:44.744 -> Rx: 55 03 04 00 00 00 C9 2F A0
09:12:44.787 -> Tx: 55 03 04 23 00 02 39 25
09:12:44.833 -> Rx: 55 03 04 00 00 00 84 EF 95
09:12:44.910 -> Tx: 55 03 04 27 00 02 78 E4
09:12:45.020 -> Rx: 55 03 04 00 00 00 00 EF F6
09:12:45.066 -> Tx: 55 03 04 2B 00 02 B8 E7
09:12:45.113 -> Rx: 55 03 04 00 00 00 00 EF F6
09:12:45.159 -> Tx: 55 03 04 2F 00 02 F9 26
09:12:45.237 -> Rx: 55 03 04 A8 5C 00 02 8E 45
09:12:45.284 -> Tx: 55 03 04 33 00 02 38 E0
09:12:45.376 -> Rx: 55 03 04 00 00 00 00 EF F6
09:12:45.469 -> Tx: 55 03 10 00 00 01 8D 1E
09:12:45.862 -> Timeout waiting for RS485 response.  Likely no more data coming.
09:12:45.932 -> Timed Out (inByteNumZeroIndexed): 0
09:12:45.965 -> Timed Out (gotSlaveID): 0
09:12:45.999 -> Timed Out (gotFunctionCode): 0
09:12:46.032 -> Timed Out (resp->functionCode): 0
09:12:46.065 -> Timed Out (gotData): 0
09:12:46.065 -> Timed Out (resp->dataSize): 0
09:12:46.099 -> Rx: Nothing

[Spookster]

Should I be concerned about the Ardrino output errors on building? eg:

C:\Temp\Alpha2MQTT-master\Alpha2MQTT\RS485Handler.cpp: In member function 'void RS485Handler::outputFrameToSerial(bool, uint8_t*, byte)':
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\RS485Handler.cpp:124:10: warning: 'char* strncat(char*, const char*, size_t)' specified bound 4 equals source length [-Wstringop-overflow=]
  124 |   strncat(_debugOutput, "Tx: ", 4);
      |   ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\RS485Handler.cpp:128:10: warning: 'char* strncat(char*, const char*, size_t)' specified bound 4 equals source length [-Wstringop-overflow=]
  128 |   strncat(_debugOutput, "Rx: ", 4);
      |   ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\RS485Handler.cpp:133:10: warning: 'char* strncat(char*, const char*, size_t)' specified bound 7 equals source length [-Wstringop-overflow=]
  133 |   strncat(_debugOutput, "Nothing", 7);
      |   ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\RS485Handler.cpp:143:12: warning: 'char* strncat(char*, const char*, size_t)' specified bound 1 equals source length [-Wstringop-overflow=]
  143 |     strncat(_debugOutput, " ", 1);
      |     ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
In file included from C:\Temp\Alpha2MQTT-master\Alpha2MQTT\RegisterHandler.h:33,
                 from C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:15:
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino: In function 'void sendData()':
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Definitions.h:46:21: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
   46 | #define DEVICE_NAME "Alpha2MQTT"
      |                     ^
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:1058:82: note: in expansion of macro 'DEVICE_NAME'
 1058 |   sendDataFromAppropriateArray(_mqttTenSecondStatusRegisters, numberOfRegisters, DEVICE_NAME MQTT_MES_STATE_SECOND_TEN);
      |                                                                                  ^~~~~~~~~~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Definitions.h:46:21: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
   46 | #define DEVICE_NAME "Alpha2MQTT"
      |                     ^
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:1065:82: note: in expansion of macro 'DEVICE_NAME'
 1065 |   sendDataFromAppropriateArray(_mqttOneMinuteStatusRegisters, numberOfRegisters, DEVICE_NAME MQTT_MES_STATE_MINUTE_ONE);
      |                                                                                  ^~~~~~~~~~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Definitions.h:46:21: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
   46 | #define DEVICE_NAME "Alpha2MQTT"
      |                     ^
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:1072:83: note: in expansion of macro 'DEVICE_NAME'
 1072 |   sendDataFromAppropriateArray(_mqttFiveMinuteStatusRegisters, numberOfRegisters, DEVICE_NAME MQTT_MES_STATE_MINUTE_FIVE);
      |                                                                                   ^~~~~~~~~~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Definitions.h:46:21: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
   46 | #define DEVICE_NAME "Alpha2MQTT"
      |                     ^
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:1079:80: note: in expansion of macro 'DEVICE_NAME'
 1079 |   sendDataFromAppropriateArray(_mqttOneHourStatusRegisters, numberOfRegisters, DEVICE_NAME MQTT_MES_STATE_HOUR_ONE);
      |                                                                                ^~~~~~~~~~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Definitions.h:46:21: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
   46 | #define DEVICE_NAME "Alpha2MQTT"
      |                     ^
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:1086:79: note: in expansion of macro 'DEVICE_NAME'
 1086 |   sendDataFromAppropriateArray(_mqttOneDayStatusRegisters, numberOfRegisters, DEVICE_NAME MQTT_MES_STATE_DAY_ONE);
      |                                                                               ^~~~~~~~~~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino: In function 'void sendDataFromAppropriateArray(mqttState*, int, char*)':
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:1103:38: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 1103 |  resultAddedToPayload = addToPayload("{\r\n");
      |                                      ^~~~~~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:1122:40: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 1122 |    resultAddedToPayload = addToPayload("}");
      |                                        ^~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino: In function 'void mqttCallback(char*, byte*, unsigned int)':
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:1590:39: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 1590 |     resultAddToPayload = addToPayload("{\r\n");
      |                                       ^~~~~~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:1608:41: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 1608 |       resultAddToPayload = addToPayload("}");
      |                                         ^~~
C:\Temp\Alpha2MQTT-master\Alpha2MQTT\Alpha2MQTT.ino:1762:37: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 1762 |   resultAddToPayload = addToPayload("{\r\n");
      |                                     ^~~~~~~

[Spookster]

And running slave address finder :

[Spookster]

Wait! success! I was looking through the alpha web management and came across an upgrade that hadnt been applied. I didnt screen shot it as I didnt think it would be relevant, but something like BMS 1.02 to 1.03

After applying that, its working! So it seems the BMS update cured the problem

Thank you so much for your assistance and work on the project! Ive had the ESS for over a year now, and its one thing that has bugged me, having to rely on responses from the ESS servers for information for the home automation, so this should sort that issue out

[Spookster]

There are a few weird and inconsistent values coming through, but I guess Ill give it a few days to settle and get some history.

Do the values vary from model to model?

[dxoverdy]

That’s great news! I noticed in one of your earlier messages you were getting responses back to certain messages, but not others:

09:12:45.376 -> Rx: 55 03 04 00 00 00 00 EF F6 09:12:45.469 -> Tx: 55 03 10 00 00 01 8D 1E 09:12:45.862 -> Timeout waiting for RS485 response. Likely no more data coming.

As for inconsistent values, tell me what you’re seeing for one register in particular and we can take it from there.

Congrats again!

On Mon, 22 May 2023 at 03:03, Spookster @.***> wrote:

There are a few weird and inconsistent values coming through, but I guess Ill give it a few days to settle and get some history.

Do the values vary from model to model?

— Reply to this email directly, view it on GitHub https://github.com/dxoverdy/Alpha2MQTT/issues/10#issuecomment-1556405062, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZC7OYNGR4P3UE5MIVQEDL3XHLCQ5ANCNFSM6AAAAAAYINLYZM . You are receiving this because you commented.Message ID: @.***>

[Spookster]

My initial queries were around weird spikes in load and consumption Obviously Im not consuming 800+ kw :)

[Spookster]

Thats caused by data spike like so:

[dxoverdy]

Its not beyond the realms of possibility the calculations I have which create REG_CUSTOM_LOAD are wrong....

When you are seeing load reporting ridiculous figures again, can you send me a raw ten send state payload from MQTT Explorer?

LOAD is calculated by using the following values from that ten second state

REG_PV_METER_R_TOTAL_ACTIVE_POWER_1 REG_INVERTER_HOME_R_PV1_POWER_1 REG_INVERTER_HOME_R_PV2_POWER_1 REG_INVERTER_HOME_R_PV3_POWER_1 REG_INVERTER_HOME_R_PV4_POWER_1 REG_INVERTER_HOME_R_PV5_POWER_1 REG_INVERTER_HOME_R_PV6_POWER_1 REG_GRID_METER_R_TOTAL_ACTIVE_POWER_1 REG_BATTERY_HOME_R_BATTERY_POWER

My hope is that one of those of those is high which will give me a focal point, because at the moment the calculations look right...

Thanks

[Spookster]

I havent had a chance to have a close look at your calcs yet, but will

And from a different NR component:

[Spookster]

When you say to get the values from MQTT explorer, can you go back and fetch that historical data? These were the figures over night:

From a base:

[Spookster]

Here we go: Before spike

Actual spike:

After Spike:

The only thing I note, which is odd, is the REG_INVERTER_HOME_R_INVERTER_TEMP disappears during the spike? The inverter temp also seems like an incorrect value at 3.4

[Spookster]

(Sorry for all the posts!) I did some more monitoring, and of interest I enabled CONSUMPTION in node red (just debug output) and it was unaffected by the spike (so calc issue in RegisterHandler.cpp?):

[Spookster]

After monitoring CONSUMPTION, it also spiked. Perhaps its an issue with the ESS sending corrupt data?

[dxoverdy]

Good investigatory work - indeed CONSUMPTION was done at the javascript/node red level as opposed to on the chip. I'm shocked that is affected, I've just spent the last ten minutes thinking it was likely an overflow or underflow, but I think that's kyboshed that thought.

I'm interested in the raw bytes for REG_CUSTOM_LOAD. Can you ping the following message to it when it is reporting a spike?

Topic: Alpha2MQTT/request/read/register/handled Payload: { "registerAddress": "0xFFFE" }

You'll get a response on Alpha2MQTT/response/read/register/handled Thanks

[Spookster]

Data affected:

[Spookster]

I'm interested in the raw bytes for REG_CUSTOM_LOAD. Can you ping the following message to it when it is reporting a spike?

Am I able to ping a specific time? Im not sure how I get that data for the 10 second window it happens

[dxoverdy]

At any point in Home Assistant's history for .... haha you've just posted it a pic.

Is it just Grid Power which goes off the rails? The three power figures which contribute to 'load' are PV power, grid power and battery power.

[Spookster]

Yes, just Grid This is the filter without the GRID and calculated values :

[dxoverdy]

Awesome, thanks. Could you post the same graph with just grid power for the same period?

[Spookster]

Just GRID:

[dxoverdy]

Could you narrow the graph to just show this period?

[Spookster]

Just exporting power :

[dxoverdy]

Humour me will you and give me a bit of an idea of your system. Are you single or three phase, do you have a grid meter inside your consumer unit which tells the Alpha what grid usage you have, or is it a CT clamp?

[Spookster]

Single phase, CT clamp inside switch board

[Spookster]

Or would you call that a grid meter? The solar CT is the black one

[dxoverdy]

That makes sense. The CT is wrapped around your PV to tell the Alpha what you're making, and the grid meter with the LCD tells the Alpha what the grid is doing. Can you cycle through the functions to display power? I appreciate you can't exactly stay sat in front of it seeing if it periodically displays stupidly high figures, but it would be good if watched for a period of time to see if spurious figures get spat out.

Further, you have a couple of days worth of blips now I think? Are the blips at a similar time during the day?

[Spookster]

Fairly random Id suggest

[Spookster]

Theres quite a few figures to scroll through - any ideas what it may be called?

I guess ultimately, I could filter out stupidly high values at a code level

[dxoverdy]

What I said earlier was slightly wrong. The CT clamp is around the live of your main incoming and tells the ACR what the grid usage is. Do you have a separate solar clamp elsewhere?

[Spookster]

Not that Im aware of, if so its out of view somewhere

[Spookster]

The blue network cable supplies data from the RJ45 of the ESS

[dxoverdy]

If you cycle through, anything suggests active power?