[erledigt] Frage/Klarstellung zu EBus

Begonnen von delMar, 27 März 2018, 10:55:08

Vorheriges Thema - Nächstes Thema

delMar

Hallo!

ich hoffe, ich bin hier richtig.
Es geht darum, dass ich auf einer Wiki-Seite zwar ein Problem geschildert sehe, das ich auch habe, allerdings die Lösung dazu nicht angeführt ist.
Ich kann also leider nur auf das "Problem" aufmerksam machen, die Lösung dazu aber hier (noch) nicht dazu liefern.
Da ich keinen Wiki-Account habe, konnte ich auch die in der History angeführten Benutzer nicht selber kontaktieren.
Ich möchte hier also garnicht unbedingt um die Lösung des Problems bitten, sondern wäre auch schon sehr dankbar für Hinweise, wie ich an die richtigen Personen gelange :-)

Auf der Seite https://wiki.fhem.de/wiki/EBUS#Bekannte_Fehler ist folgender Absatz zu finden:

2015-11-29 06:26:55.271 [update notice] update myCustom1 Status11: nosignal;40;0;15;-;-;-;-;-0.188
2015-11-29 06:26:55.541 [update notice] update myCustom Status02: auto;60;70.0;70;54.0
2015-11-29 06:26:59.293 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:03.323 [update notice] update myCustom Status01: 53.0;45.0;-0.438;47.0;46.0;error
2015-11-29 06:27:05.268 [update notice] update broadcast outsidetemp QQ=10: -3.188
2015-11-29 06:27:09.344 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:11.934 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:11.981 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.025 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.069 [bus error] send to 08: ERR: read timeout

In diesem Fall liegt ein Fehler bei jedem Sendeversuch vor. Ein "bus error" mit timeout sollte nicht (zu oft) zu finden sein. Gut zu sehen sind schon die Broadcast Meldungen, die selbständig über den Bus laufen und vom Konverter schon richtig interpretiert werden. Sollten wie in diesem Fall, die Meldungen nicht mit Texten zu lesen sein fehlen noch die Konfigurationfiles (csv) im Verzeichnis /etc/ebusd. Welche Files hier verwendet werden sollen ist natürlich von der Therme und dem Zubehör abhängig.


Soweit, so gut. Meine Frage bezieht sich auf die ersten beiden Sätze im Text:
ZitatIn diesem Fall liegt ein Fehler bei jedem Sendeversuch vor. Ein "bus error" mit timeout sollte nicht (zu oft) zu finden sein.
Wie löse ich dieses Problem nun? Im Absatz unmittelbar davor wird erläutert, wie man merkt, dass der Poti uU noch nicht richtig eingestellt und wann er schlussendlich doch richtig eingestellt ist.
Bedeutet dieser read timeout nun, dass doch noch am Poti optimiert werden muss?

Lange Rede, kurzer Sinn: es wäre spitze, wenn dem hier gezeigtem Absatz noch ein Satz zur Lösung des bus error timeouts hinzugefügt werden würde.


Danke!

schöne Grüße
Martin
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

delMar

Update: Ich habe rausgefunden, dass der Wiki Eintrag 1:1 von einem Forums-Eintrag kopiert wurde (der leider aus beinahe 200 Seiten besteht, weswegen das nicht gleich ersichtlich war).
Ich werde mich also dort um eine Antwort bemühen und dann mit dem Korrekturvorschlag zurückkommen

Ich markiere das hier mal mit erledigt, da ich ja nun weiß, wie's weitergeht.

schöne Grüße
Martin
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.