Probleme beim verbinden per Modbus-TPC bei Nutzung eines Modbus-Stufenschalters
Closed this issue · 6 comments
In der Version 2.3.0 des Smart Appliance Enabler installiert auf einem Raspberry Pie 3B mittels der Standard-Installation habe ich folgendes Problem:
Wenn ich für einen Verbraucher einen Modbus Stufenschalter anlege bekommt der SAE keine Verbindung zum verwendeten mbusd.
Das Logging zeigt folgende Ausgaben:
`2023-06-04 11:26:58,567 TRACE [MQTT Call: F-05192419-000000000001-00-EnergyRequest-6] d.a.s.s.EnergyRequest [AbstractRequest.java:168] F-05192419-000000000001-00: MQTT message received: VariablePowerConsumerMessage{on=false, power=0, useOptionalEnergy=null}
2023-06-04 11:26:58,847 TRACE [Timer-0] d.a.s.u.GuardedTimerTask [GuardedTimerTask.java:54] F-05192419-000000000001-00: Executing timer task name=MqttPublish-ModbusSwitch id=16312163
2023-06-04 11:26:58,849 ERROR [Timer-0] d.a.s.m.ModbusSlave [ModbusSlave.java:92] F-05192419-000000000001-00: Cannot connect to modbus USB
2023-06-04 11:26:58,851 TRACE [pool-16-thread-1] d.a.s.m.MqttClient [MqttClient.java:274] F-05192419-000000000001-00-MQTT-ModbusSwitch: Publish message: topic=sae/F-05192419-000000000001-00/WrappedControl-3 payload={"on":false,"time":"2023-06-04T11:26:58.849969","type":"ControlMessage"} retained=false
`
Verwende ich die gleiche Modbus Konfiguration mit einem normalen Schalter und greife auf die selben Register zu ergeben sich keine Probleme.
Ein Zugriff über die gleiche mbusd Instanz per mbpoll auf die Register funktioniert ebenfalls ohne Probleme.
Kannst Du mir bitte ein vollständiges Log-File verfügbar machen (DropBox, Google Drive, ...), das auch einen SAE-Start enthält?
Ich konnte den Fehler reproduzieren und habe bei der Gelegenheit die Initialisierung von Modbus und GPIO insgesamt etwas überarbeitet. Auf einem meiner produktiven Raspis läuft es bereits.
Du kannst diese Version auch testen und mir Feedback geben: https://drive.google.com/file/d/1MXrkwyFwBM7TOHbQ24OSp42UQXaM0TNc/view?usp=sharing
Vielen Dank für den schnelle Fix. Ich habe die Version aufgespielt und konfiguriert. Die Kommunikation funktioniert jetzt und der SHM schaltet wie konfiguriert.
Mit der Testversion habe ich das Problem das aktuell der Verbraucher nicht mehr abgeschaltet wird. Der Verbraucher wird zwar korrekt gesteuert, aber nach Ablauf der Zeit erfolgt keine Abschaltung mehr.
Unter Tags kommandiert der SHM auch Unterbrechungen.
grep "control request" rolling-2023-07-05.log
`...
2023-07-05 16:54:17,173 DEBUG [http-nio-8080-exec-3] d.a.s.s.w.SempController [SempController.java:300] F-05192419-000000000003-00: Received control request: on=false
2023-07-05 16:57:17,080 DEBUG [http-nio-8080-exec-5] d.a.s.s.w.SempController [SempController.java:300] F-05192419-000000000003-00: Received control request: on=true, recommendedPowerConsumption=2000W
2023-07-05 16:58:17,161 DEBUG [http-nio-8080-exec-1] d.a.s.s.w.SempController [SempController.java:300] F-05192419-000000000003-00: Received control request: on=true, recommendedPowerConsumption=2000W
2023-07-05 16:59:17,760 DEBUG [http-nio-8080-exec-8] d.a.s.s.w.SempController [SempController.java:300] F-05192419-000000000003-00: Received control request: on=true, recommendedPowerConsumption=2000W
2023-07-05 17:00:17,486 DEBUG [http-nio-8080-exec-3] d.a.s.s.w.SempController [SempController.java:300] F-05192419-000000000003-00: Received control request: on=true, recommendedPowerConsumption=4000W
`
Hier das vollständige Log:
https://drive.google.com/file/d/1oiXi8ZKePbUa9E0vLS0fjTWYtOjpaHES/view?usp=sharing
Um 2023-07-05 17:00:15,535 wird das Gerät eigentlich abgeschaltet:
INFO [MQTT Call: F-05192419-000000000003-00-LevelSwitch-0] d.a.s.c.LevelSwitch [LevelSwitch.java:234] F-05192419-000000000003-00: Setting power to 0W
Um 2023-07-05 17:00:17,486 kommt ein Control request
DEBUG [http-nio-8080-exec-3] d.a.s.s.w.SempController [SempController.java:300] F-05192419-000000000003-00: Received control request: on=true, recommendedPowerConsumption=4000W
und schaltet das ganze wieder ein.
Um 2023-07-05 16:59:55,857 fragt der SHM den Status des SAE ab, wobei der SAE mitteilt, dass er Schaltbefehle des SHM akzeptiert (eMSignalsAccepted=true). Enthalten ist auch ein Timeframe, der aber nur noch 4 Sekunden übrigen hat (0s-4s:0Wh/56501Wh).
Um 2023-07-05 17:00:15,531 wird der Timeframe deaktiviert, da er abgelaufen ist. Zwei Sekunden später ( 2023-07-05 17:00:17,486) schickt der SHM trotzdem einen Einschaltbefehl. Diesen Einschaltbefehl hätte der SHM nicht senden dürfen, da der Timeframe bereits abgelaufen ist. Der SAE hat sich korrekt verhalten, insofern schliesse ich den Bug (zumal das Problem mit dem eigentlichen Bug nichts zu tun hatte).