VBus in fhem

[pejonp]

@mcchina

2 Sachen:
Bitte setzte deinen Code in entsprechen Tags (#).
HTTPMOD ist nicht vbus. Bitte zu diesem Thema im entsprechenden Forum nachfragen.

So wie ich das verstehe ist das Token abgelaufen und es können keine Daten mehr vom DL2 geholt werden.

pejonp

[HeikoE]

@HeikoE

setz doch mal dein  event-min-interval  auf  120. Wenn so viele Daten geliefert werden, wird der Speicher ja nicht geleert ??

event-min-interval .*:3600

Was hast du für ein Perl (v5.24.1)? Ist FHEM aktuell ?
Wo schreibst du deinen log hin ? Ist die SD-Karte schnell oder USB-Stick ?

Du kannst ja mal SYSMON installieren um zu sehen was dein raspi macht.
defmod rasp3i SYSMON
attr rasp3i room SYSMON

Code Auswählen Erweitern


Internals:
   INTERVAL_BASE 60
   INTERVAL_MULTIPLIERS 1 1 1 10
   MODE       local
   NAME       rasp3i
   NR         435
   STATE      Initialized
   TYPE       SYSMON
   READINGS:
     2018-03-10 18:49:06   cpu0_freq       600
     2018-03-10 18:49:06   cpu0_freq_stat  600.00 1200.00 712.51
     2018-03-10 18:49:07   cpu0_idle_stat  0.00 99.93 90.20
     2018-03-10 18:49:06   cpu1_freq       600
     2018-03-10 18:49:06   cpu1_freq_stat  600.00 1200.00 712.51
     2018-03-10 18:49:07   cpu1_idle_stat  17.10 100.00 93.22
     2018-03-10 18:49:06   cpu2_freq       600
     2018-03-10 18:49:06   cpu2_freq_stat  600.00 1200.00 712.51
     2018-03-10 18:49:07   cpu2_idle_stat  1.52 100.00 97.16
     2018-03-10 18:49:06   cpu3_freq       600
     2018-03-10 18:49:06   cpu3_freq_stat  600.00 1200.00 712.51
     2018-03-10 18:49:07   cpu3_idle_stat  0.04 100.00 96.64
     2018-03-06 22:44:56   cpu_bogomips    76.80
     2018-03-10 18:49:07   cpu_core_count  4
     2018-03-10 18:49:06   cpu_freq        600
     2018-03-10 18:49:06   cpu_freq_stat   600.00 1200.00 712.51
     2018-03-10 18:49:07   cpu_idle_stat   63.26 97.59 94.36
     2018-03-06 22:44:56   cpu_model_name  ARMv7 Processor rev 4 (v7l)
     2018-03-10 18:49:07   cpu_temp        52.62
     2018-03-10 18:49:07   cpu_temp_avg    52.4
     2018-03-10 18:49:07   cpu_temp_stat   0.00 55.31 52.36
     2018-03-10 18:49:07   eth0            RX: 0.00 MB, TX: 0.00 MB, Total: 0 MB
     2018-03-10 18:49:07   eth0_diff       RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
     2018-03-10 18:49:07   eth0_rx         0
     2018-03-10 18:49:07   eth0_speed      10
     2018-03-10 18:49:07   eth0_tx         0
     2018-03-10 18:49:07   fhemstarttime   1520372639
     2018-03-10 18:49:07   fhemstarttime_text 06.03.2018 22:43:59
     2018-03-10 18:49:07   fhemuptime      331507
     2018-03-10 18:49:07   fhemuptime_text 3 days, 20 hours, 05 minutes
     2018-03-10 18:49:07   idletime        915087 93.00 %
     2018-03-10 18:49:07   idletime_text   10 days, 14 hours, 11 minutes (93.00 %)
     2018-03-10 18:49:07   loadavg         0.17 0.25 0.21
     2018-03-06 22:44:56   perl_version    v5.24.1
     2018-03-10 18:49:07   ram             Total: 939.22 MB, Used: 200.68 MB, 21.37 %, Free: 332.16 MB
     2018-03-10 18:49:07   ram_used_stat   88.95 694.89 201.01
     2018-03-10 18:48:07   root            Total: 29084 MB, Used: 4236 MB, 16 %, Available: 23635 MB at /
     2018-03-10 18:49:07   starttime       1519720176
     2018-03-10 18:49:07   starttime_text  27.02.2018 09:29:36
     2018-03-10 18:49:07   stat_cpu        12540844 0 5630173 366034985 201728 0 957865
     2018-03-10 18:49:07   stat_cpu0       3653115 0 1065902 86324200 104222 0 531027
     2018-03-10 18:49:07   stat_cpu0_diff  844 0 61 4731 1 0 43
     2018-03-10 18:49:07   stat_cpu0_percent 14.86 0.00 1.07 83.29 0.02 0.00 0.76
     2018-03-10 18:49:07   stat_cpu0_text  user: 14.86 %, nice: 0.00 %, sys: 1.07 %, idle: 83.29 %, io: 0.02 %, irq: 0.00 %, sirq: 0.76 %
     2018-03-10 18:49:07   stat_cpu1       1903578 0 2949874 91909292 55139 0 388684
     2018-03-10 18:49:07   stat_cpu1_diff  17 0 259 5631 1 0 26
     2018-03-10 18:49:07   stat_cpu1_percent 0.29 0.00 4.36 94.89 0.02 0.00 0.44
     2018-03-10 18:49:07   stat_cpu1_text  user: 0.29 %, nice: 0.00 %, sys: 4.36 %, idle: 94.89 %, io: 0.02 %, irq: 0.00 %, sirq: 0.44 %
     2018-03-10 18:49:07   stat_cpu2       3728066 0 775931 93693971 22934 0 19675
     2018-03-10 18:49:07   stat_cpu2_diff  0 0 7 5967 6 0 0
     2018-03-10 18:49:07   stat_cpu2_percent 0.00 0.00 0.12 99.78 0.10 0.00 0.00
     2018-03-10 18:49:07   stat_cpu2_text  user: 0.00 %, nice: 0.00 %, sys: 0.12 %, idle: 99.78 %, io: 0.10 %, irq: 0.00 %, sirq: 0.00 %
     2018-03-10 18:49:07   stat_cpu3       3256085 0 838466 94107522 19433 0 18479
     2018-03-10 18:49:07   stat_cpu3_diff  2 0 55 5935 2 0 0
     2018-03-10 18:49:07   stat_cpu3_percent 0.03 0.00 0.92 99.02 0.03 0.00 0.00
     2018-03-10 18:49:07   stat_cpu3_text  user: 0.03 %, nice: 0.00 %, sys: 0.92 %, idle: 99.02 %, io: 0.03 %, irq: 0.00 %, sirq: 0.00 %
     2018-03-10 18:49:07   stat_cpu_diff   863 0 382 22264 10 0 69
     2018-03-10 18:49:07   stat_cpu_percent 3.66 0.00 1.62 94.39 0.04 0.00 0.29
     2018-03-10 18:49:07   stat_cpu_text   user: 3.66 %, nice: 0.00 %, sys: 1.62 %, idle: 94.39 %, io: 0.04 %, irq: 0.00 %, sirq: 0.29 %
     2018-03-10 18:49:07   swap            n/a
     2018-03-10 18:49:07   swap_used_stat  0.00 0.00 0.00
     2018-03-10 18:49:07   uptime          983970
     2018-03-10 18:49:07   uptime_text     11 days, 09 hours, 19 minutes
     2018-03-10 18:49:07   wlan0           RX: 2797.31 MB, TX: 3092.08 MB, Total: 5889.39 MB
     2018-03-10 18:49:07   wlan0_diff      RX: 0.34 MB, TX: 0.61 MB, Total: 0.95 MB
     2018-03-10 18:49:07   wlan0_ip        192.xxx.xxx.xxx
     2018-03-10 18:49:07   wlan0_rx        2933196778
     2018-03-10 18:49:07   wlan0_speed     72.2
     2018-03-10 18:49:07   wlan0_tx        3242280090
   helper:
..
     excludes:
Attributes:
   room       SYSMON


pejonp

Hallo pejonp,

das Attribut event-min-interval .*:3600 im Zusammenspiel mit event-on-change-reading führt zu events, wenn Readings aktualisiert werden und der Wert geändert ist ODER die Zeit abgelaufen.
(siehe https://wiki.fhem.de/wiki/Event-min-interval)
Das hat nach meinem Verständnis aber alles nur mit der Erzeugung von Ereignissen bei Änderung von Readings zu tun.

Hier liegt das Problem doch irgedwo bei den Triggern, welche fhem auslöst, und damit die Routine "VBUSIF_Read" im Modul aufruft.
Laut https://wiki.fhem.de/wiki/DevIo wird "VBUSIF_Read" immer dann aufgerufen, wenn neue Daten da sind.
event-min-interval hat da keinen Einfluss.
In Deiner Sub wird dann genau ein Telegrammframe am Anfang abgearbeitet. Sind mehrere gekommen, werden sie kummuliert.
Was ich nicht verstehe ist, woher so viele Daten kommen.

Ich habe jetzt noch einen anderen Ansatz verfolgt:
Nachdem ein Telegrammframe erkannt wurde, wird der Rest gnadenlos gelöscht.
Dazu hab ich zwei Kleinigkeiten geändert:
1. Rest löschen:

Code Auswählen Erweitern


157 $data = "";#substr($data,$idx);

2. Unnötige Logeinträge unterdrücken: Verbose auf 4 gesetzt

Code Auswählen Erweitern


216      Log3 $hash->{NAME}, 4,"$name:  VBUSIF_Read_Ende: $data ";
217      #return "";

Wozu das Return da steht, verstehe ich nicht ganz, weiter unten kommt es doch sowiso. Zugegeben, $data zu retten lohnt nicht, da ja kein Telegrammanfang ("aa") drin ist. Schadet aber wohl auch nicht.

So kann natürlich was verlorengehen. Das läuft jetzt mal so über Nacht.
Bis demnächst,
Heiko

[pejonp]

@HeikoE

hier hat auch einer eine DeltaSol SLT ohne Probleme am laufen. (https://forum.fhem.de/index.php/topic,10303.msg582222.html#msg582222)
Vielleicht mal das Tool vom Hersteller runterladen und auf die Anlage zugreifen. Vielleicht kann man noch etwas einstellen.
Von wann ist die Anlage ? Protokoll geändert ?

Betriebssystem ist aktuell ? Perl ? LAN oder USB-Adapter ?
LAN-Adapter mal neu gestartet ?

pejonp

[HeikoE]

@HeikoE

hier hat auch einer eine DeltaSol SLT ohne Probleme am laufen. (https://forum.fhem.de/index.php/topic,10303.msg582222.html#msg582222)
Vielleicht mal das Tool vom Hersteller runterladen und auf die Anlage zugreifen. Vielleicht kann man noch etwas einstellen.
Von wann ist die Anlage ? Protokoll geändert ?

Betriebssystem ist aktuell ? Perl ? LAN oder USB-Adapter ?
LAN-Adapter mal neu gestartet ?

pejonp

Hallo pejonp,
Sowas hatte ich auch gelesen. Es war mit ein Punkt für mich, einen neuen Regler zu kaufen. Mein Deltasol SLT hat eine eingebaute LAN-Schnittstelle. Seine Firmware entspricht der letzten Version auf der Resol Website.
Einstellen kann man im Webinterface nur die IP-Adresse und Gerätenamen. In der Menüstruktur gibt es auch keine derartigen Einstellungen.
Fhem und Pi sind aktuell, Neustarts hatte ich auch genug. Was ich bei Gelegenheit mal tun werde, ist mittels Wireshark zu prüfen, was der Deltasol so raushaut.
Die Fritzbox kann zwar mitschneiden, was sie selbst vermittelt, aber Daten, die nur durchgeroutet werden, scheinen nicht dabei zu sein. Jedenfalls hab ich nur einige Broadcasts gesehen, die der Deltasol alle 10s generiert.
Daten scheinen viel häufiger zukommen.
Ich bin jedenfalls mit meiner gestrigen Änderung zufrieden. Bisher sieht alles gut aus.
Danke für die Geduld.
Werde am Ball bleiben und weiter berichten.
Schönen Restsonntag,
Heiko

[bjoern76]

Hallo zusammen,

ich habe die Deltasol SLT am laufen, ja.
Konfiguration hat mit der hilfe von pejonp, nachdem es als device angelegt war funktioniert.
habe mittlerweile aber das problem das mit der zeit die temperaturwerte falsch übermittelt werden.
also an dem steuergerät steht als temperatur 80 grad und im reading in fhem 60. das ist nicht nachvollziehbar und auch nicht immer genau 20 grad unterschied sondern variiert.
nach einem shutdown restart von fhem werden die korrekten werte übermittelt.
hat jemand so etwas schon gehabt?
oder eine idee was man machen kann?

Gruß
Björn

[pejonp]

Hallo bjoern76,

du bist jetzt schon der 2. mit einer DeltaSol SLT und diesem Zeitproblem. @HeikoE hatte auch das Problem und hat eine Änderung bei sich eingebaut. Ich schaue es mir bei Gelegenheit noch einmal an. Wird aber wahrscheinlich 14 Tage dauern.

pejonp

[HeikoE]

Hallo zusammen,

ich habe die Deltasol SLT am laufen, ja.
Konfiguration hat mit der hilfe von pejonp, nachdem es als device angelegt war funktioniert.
habe mittlerweile aber das problem das mit der zeit die temperaturwerte falsch übermittelt werden.
also an dem steuergerät steht als temperatur 80 grad und im reading in fhem 60. das ist nicht nachvollziehbar und auch nicht immer genau 20 grad unterschied sondern variiert.
nach einem shutdown restart von fhem werden die korrekten werte übermittelt.
hat jemand so etwas schon gehabt?
oder eine idee was man machen kann?

Gruß
Björn

Hallo Björn,
Hatte das gleiche Problem. Der SLT scheint viel mehr Daten zu senden, als verarbeitet werden. Damit wächst der Puffer immer weiter an. Das vbus-device hat ein Internal, das immer weiter anwächst. Es wird pro Trigger ein Telegrammframe abgearbeitet und gelöscht, aber mehrere angehängt. Ich wollte das mal mit Wireshark verfolgen, kam aber noch nicht dazu.
Meine Änderung war am Ende relativ klein, nur eine oder zwei Zeilen. Nach jedem erkannten Frame wird der Puffer gelöscht. Das läuft seit dem ohne Fehler und der Zeitversatz ist weg. Bin z. Z. beruflich unterwegs, kann meine Version aber gerne nochmal posten.
Gruß Heiko
Edit : Im Post 677 ist die Änderung beschrieben und angehängt.

[bjoern76]

Hallo Heiko,
danke für den Tipp bzw. die Anpassung.
Habe das vor zwei Tagen eingebaut und seitdem keine Abweichungen mehr bei den Readings.
Danke & Gruß
Björn

[Brun]

Servus,

ich habe mit den Modul ein kleines Problem.

Und zwar habe ich zwei Wärmemengenzähle am Bus. Dummerweise kann das Modul dies nicht auseinander halten.
Dies ging mal bei einer ganz alten Variante, die ich seitdem benutze.

Nachdem die Werte erst kurz richtig gelesen werden, werden sie anschließend wieder auf "0" gesetzt.

Könnte man das bitte mal nachpflegen.


Gruß Brun

[pejonp]

@brun

Was für Geräte ? Verbose=5 log anhängen. 2 identische Geräte wie sollen diese unterschieden werden ?
Welche Version von vbus ?

Pejonp

[Brun]

Der Bus erlaubt mehrere Wämemängenzähler.
Einer hat die Adresse 4011 und der Andere die 4012.

Der Bus läuft auf der alten Version.

Ein Log habe ich mal angehängt

[Brun]

Jetzt hab ich die Stelle wieder gefunden!

Folgende Zeile in der Funktion "VBUSDEV_ParsePayload($@)" ist Auskommentiert, muss aber drin bleiben sonst werden Befehle an ein anderes Gerät im Bus ausgewertet.

Code Auswählen Erweitern

return undef if ($cmd != $devtype->{cmd});

Bei mir ist das so, dass das eine Gerät zum nächsten sagt "du bist jetzt dran". Da sind keine Nutzdaten im Paket aber es wird interpretiert. Da nix drin steht bleiben die Variablen leer und alle Werte werden aus "0" gesetzt.

In der Variable "$devtype->{cmd}" steht drin welche "Commands" er auswerten soll. Normalerweise "0010". Bei mir gibt es aber noch die Commands "0030". Dieser cmd dient wahrscheinlich zur Weitergabe des Tokens.

Theoretisch sollte jeder Probleme damit haben der mehr als ein Gerät im Bus hat.


Meine Änderungen habe ich mal angehängt. Bei der Gelegenheit habe ich mal die Devices in eine extra Datei ausgelagert.

Wäre schön wenn man mal dies Übernehmen könnte.

Gruß Brun

[pejonp]

@brun

Von hier (  https://github.com/pejonp/vbus ) die neuste Version geholt ?

Pejonp

[Brun]

Die holt er sich doch automatisch beim Update. Oder was sollte mir die Dateien immer überschreiben?

Aber auch da ist diese Zeile auskommentiert.

[pejonp]

@brun

mach mal bitte ein: update all https://raw.githubusercontent.com/pejonp/vbus/master/controls_vbus.txt

du kannst das auch in fhem eintragen damit von dort die aktuellen Dateien gezogen werden. Diese stehen nicht im SVN.

update add https://raw.githubusercontent.com/pejonp/vbus/master/controls_vbus.txt


pejonp