mlnoga / rct Goto Github PK

siehe evcc #9146

folgende Fehlermeldungen:

battery 1 soc: invalid response: Cmd Response (05) Id #INVALID (4BC0F974) Data [70 60 232 0]

battery 1 soc: invalid response: Cmd Response (05) Id #INVALID (C0A7074F) Data [58 189 129 108 80 83 32 49 48 46 48 32 86 87 52 81 0 0 0 0 0 0 0 0 0 0 0 0 50 51 42 69 79 14 25 195 35 158 21 63 0 0 7 13 0 0 0 0 50 46 51 46 53 54 54 49 0 0 0 0 0 0 0 0 48 48 54 53 66 52 48 50 51 57 49 55 0 0 0 0 0 0 0 0 223 21 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]

grid energy: invalid response: Cmd Response (05) Id #INVALID (C0A7074F) Data [71 240 52 38 80 83 32 56 46 48 32 68 83 76 69 0 0 0 0 0 0 0 0 0 0 0 0 0 119 61 110 69 200 249 61 193 0 0 0 63 0 0 5 13 0 0 0 0 50 46 51 46 53 54 54 49 0 0 0 0 0 0 0 0 48 48 54 53 66 52 56 50 51 50 52 54 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]

Here we go:

> golangci-lint run *.go

build_test.go:11:18: undeclared name: `BatteryPower` (typecheck)
	{Datagram{Read, BatteryPower, nil}, "[2B 01 04 40 0F 01 5B 58 B4]"},
	                ^
build_test.go:12:18: undeclared name: `InverterACPower` (typecheck)
	{Datagram{Read, InverterACPower, nil}, "[2B 01 04 DB 2D 2D 69 AE 55 AB]"},
	                ^
build_test.go:31:9: parser.Init undefined (type DatagramParser has no field or method Init) (typecheck)
	parser.Init()
	       ^
build_test.go:36:10: parser.Buffer undefined (type DatagramParser has no field or method Buffer, but does have buffer) (typecheck)
		parser.Buffer = builder.Bytes()
		       ^
build_test.go:37:10: parser.Len undefined (type DatagramParser has no field or method Len) (typecheck)
		parser.Len = len(builder.Bytes())

Quite often the response received by the rct power storage is flawed. As this behavior cannot be changed easily, I suggest to implement an effective error handling routine. I experimented with different approaches, the following (quickly translated by chatgpt into go) solved the issue and enabled stable performance:

// Query-Funktion mit robuster Fehlerbehandlung und Wiederholungslogik
func (c *Connection) Query(id Identifier) (*Datagram, error) {
	if dg, ok := c.cache.Get(id); ok {
		return dg, nil
	}

	const maxRetries = 10
	const startDelay = 100 * time.Millisecond
	const backoffMultiplier = 2
	var delay = startDelay

	for attempt := 0; attempt < maxRetries; attempt++ {
		c.builder.Build(&Datagram{Cmd: Read, Id: id, Data: nil})
		_, err := c.Send(c.builder)
		if err != nil {
			return nil, err
		}

		dg, err := c.Receive()
		if err != nil {
			if _, ok := err.(RecoverableError); ok {
				fmt.Printf("Recoverable error during parsing, attempt %d of %d: %v\n", attempt+1, maxRetries, err)
				time.Sleep(delay)
				delay *= time.Duration(backoffMultiplier)
				continue
			}
			return nil, err
		}

		if dg.Cmd == Response && dg.Id == id {
			c.cache.Put(dg)
			return dg, nil
		}

		err = RecoverableError{fmt.Sprintf("Mismatch of requested read of id: %v and response from source: %v", id, dg)}
		fmt.Println(err.Error())
		time.Sleep(delay)
		delay *= time.Duration(backoffMultiplier)
	}

	return nil, errors.New(fmt.Sprintf("Max retries reached for id: %v", id))
}

The idea behind the code:
By scheduling strategic delays between retries, the likelihood of subsequent requests being successful is increased, leading overall to a more resilient application.

What do you think about the suggestion? Can you implement such a routine or something else increasing reliability?

I am using this module to read Inverter state (8 values) every second with a Raspberry Pi Zero W in my garage in order to control the charger wall box for electric car. After few hours, but mostly after 4 to 15 days the app crashes while trying to read a value.

Evcc connects with timeout: 1s per default. That value is applied to both the connection timeout as well as the cache duration. 1s is a very aggressive connection timeout. Simple approach would be to split these params or- alternatively- allow passing a Context as first param to use with DialContext.