Lambda: support for excess energy specified in negative numbers #21972
Conversation
There was a problem hiding this comment.
Hey @anbie - I've reviewed your changes - here's some feedback:
- Consolidate the repeated Modbus URI blocks into a shared variable or template to reduce duplication.
- Add a guard or diagnostic in the
negativeexcess mode to catch the known zero-overwrite issue when scaling power writes.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consolidate the repeated Modbus URI blocks into a shared variable or template to reduce duplication.
- Add a guard or diagnostic in the `negative` excess mode to catch the known zero-overwrite issue when scaling power writes.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
Wenn ich in die plugin/modbus.go ein Print mit einbaue sieht man, dass da schon nur noch -0 ankommt: return func(val float64) error {
val *= m.scale
fmt.Println(val)
switch op.FuncCode {
case gridx.FuncCodeWriteSingleCoil:
var uval uint16
if val != 0 {
uval = 0xFF00
}
_, err = m.conn.WriteSingleCoil(op.Addr, uval)
return errVmtl. passiert der Fehler vorher im Template. |
|
Gute Frage – ich bin leider auch noch nicht weitergekommen, was genau mit dem Wert passiert. |
|
Da ich in Go nicht ganz zu Hause bin, habe ich etwas mit Trace-Statements in der writeFunc() experimentiert, um das Verhalten besser zu verstehen. Was mir dabei aufgefallen ist:
|
|
Es sieht so aus, als würde encode Probleme haben mit negativen Werten. Trace Output modbus.go: register.go: Wenn ich val = 5 mache, dann sieht das so aus: |
|
Es liegt also an der übergebenen encode Funktion. Bzw. an der inneren fun() |
|
Ich habe in dem Zusammenhang einiges über Go dazugelernt – das Problem versteckt sich in util/modbus/register.go in der EncodeFunc(): Ich habe das mal ersetzt mit diesem Code, um auch negative Werte korrekt in die Lambda zu bekommen: Vollständige Transparenz: Ich bin in Go nicht wirklich tief drin und habe mir bei der Umsetzung Unterstützung von ChatGTP geholt. Daher kann ich schwer einschätzen, ob der Ansatz hier „gut“ und elegant gelöst ist – Feedback, Anmerkungen oder Verbesserungsvorschläge sind sehr willkommen! 🙏 |
|
Vorschlag für die case strings.HasPrefix(enc, "int"):
return r.encodeToBytes(func(v float64) uint64 {
return uint64(int64(v))
})
case strings.HasPrefix(enc, "uint"):
return r.encodeToBytes(func(v float64) uint64 {
return uint64(v)
})ob/wie das downscaling des Vorzeichens funktioniert bräuchte einen Unit Test, aber erstmal reichts das auszuprobieren ;) |
|
Hab Deinen Vorschlag eingebaut und kurzen Unit-Test gemacht: das sieht vielverspechend aus. Die Data Payload, die zur Lambda Register 102 geschickt wird, ist 0xD4E0 -> "-11008". |
Removed 2 trailing spaces in line 36. I missed them before 🙄
#20238
This PR introduces two enhancements to the lambda-zewotherm template:
1. Inverted Power Write for Negative Excess Mode
Adds support for inverting the power value written via Modbus when operating in "negative excess" mode.
2. Customizable Modbus TCP Port
Introduces a new port parameter, allowing users to override the default Modbus TCP port 502.
As noted in #20238, there is still an outstanding issue when using the "negative" mode: negative values are being overwritten with 0 during processing. Further investigation is needed.