Problem:
Zitat von: krikan am 22 August 2014, 10:41:06
Ich stecke meinen USB300 wegen Systemumstellung derzeit abwechselnd an 2 Fhem-PCs an. Sobald ich die Fhem-Instanz ohne USB300 neu starte, bleibt Fhem trotz/wegen autocreate beim Start hängen. Letzter Log-Eintrag "get TCM310_0 baseid". Bevor ich das mal verstanden hatte, hat es leider etwas gedauert. Gibt es hier eine mögliche automatische Lösung. Also Abbruch "get TCM310_0 baseId", wenn nach 3 Sekunden keine Antwort (internaltimer o.ä.)
Lösungsvorschlag:
File: 00_TCM.pm
Zeile: 520
- return DevIo_OpenDev($hash, 1, undef)
if($hash->{STATE} eq "disconnected");
+ return DevIo_OpenDev($hash, 1, undef)
if($hash->{STATE} ne "opened");
und Zeile: 593
- Log3 undef, 1, TCM $name $err;
+ Log3 undef, 1, "TCM $name $err";
Danke für die Vorschläge.
- Die Log3-Zeile werde ich berichtigen.
- @flurin: Wurde die Änderung zum Aufruf der Routine DevIo_OpenDev mit TCM-Transceivern und RS-232-Wandlern getestet?
- @Rudi: Bitte klären, ob die vorgeschlagenen Änderungen zum Aufruf der Routine DevIo_OpenDev im Sinne des Erfinders oder ob Nebenwirkungen zu erwarten sind. Ich kann das nicht beurteilen. Danke!
Zitat von: klaus.schauer am 24 August 2014, 21:32:07
- @flurin: Wurde die Änderung zum Aufruf der Routine DevIo_OpenDev mit TCM-Transceivern und RS-232-Wandlern getestet?
getestet mit einem USB 300 (TCM-Transceiver), einen RS-232-Wandler habe ich nicht. (OS X 10.9.4, krikan hat es auch mit anderen OS's getestet) Aber dies ist in diesem Zusammenhang vermutlich nicht entscheidend.
Wenn Du folgendes vor dem DevIo_OpenDev Aufruf einfügst:
my $name = $hash->{NAME};
Log3 $name, 2, "Debugging TCM: $name $hash->{STATE}";dann ist $hash->{STATE} = "initialized", also DevIo_OpenDev wird in diesem Fall nicht aufgerufen (eq "disconnected" => false).
Soweit ich sehe, DevIo setzt als status nur disconnected und opened.
DevIo_Expect zaehlt nicht, da es sich blockiert, und deswegen nicht verwendet werden sollte.
-> Ich verstehe nicht, wieso die Aenderung einen Unterschied macht. Kann mir jemand den Status (STATE) im Problemfall zeigen?
Zitat von: rudolfkoenig am 25 August 2014, 07:43:59
-> Ich verstehe nicht, wieso die Aenderung einen Unterschied macht. Kann mir jemand den Status (STATE) im Problemfall zeigen?
siehe oben, rot markiert
@flurin: Das ist alles huebsch, aber keine Antwort auf meine Frage.
initialized wird, soweit ich es sehen kann, im TCM_Notify gesetzt, wenn die Initialisierung fertig ist (global:INITIALIZED), und dabei wird ignoriert, ob die Verbindung zu TCM geoeffnet werden konnte oder nicht -> das sollte gefixed werden.
@klaus: falls du in NotifyFn nur nach global Nachrichten suchst, dann ist es sinnvoll
$hash->{NOTIFYDEV} = "global";
zu setzen
@klaus.schauer: Da ich sehe, dass Du sehr aktiv an dem Problem arbeitest (und ich wohl der Auslöser war): Wenn Du Tester brauchst, melde Dich bitte. Gruß, Christian
@klaus.schauer: Ich kann momentan auf dem CT auch testen, da ich dort FHEM noch nicht voll produktiv betreibe.
Gruß Helmut
@klaus.schauer
Falls Du länger brauchst, um in Ruhe alles zu testen, würde ich vorschlagen, die oben beschriebenen Änderungen provisorisch vorzunehmen.
Mit der geänderten Version habe ich keine Probleme und soviel ich weiss Christian auch nicht.
Gruss
flurin
Anhang: 00_TCM.pm mit den Änderungen
Ich kann die Auswirkungen nicht beurteilen. Deshalb hatte ich gebeten, dies in unterschiedlichen Konstellationen zu testen. Auch Rudi hatte doch weitere Informationen erbeten.
Hallo Klaus,
da ich den (aus meiner Sicht) "Kleinkram" ins Rollen gebracht habe:
Ist es überhaupt sinnvoll, wenn wir Anwender mit der obigen Version weitertesten? Ich hatte beim Mitlesen der Beiträge von Rudi und Dir den festen Eindruck, dass es letztlich auf eine andere Lösung des Problems hinausläuft und darum meinen Testwillen für diese andere Lösung bekundet. Vielleicht habe ich das auch mißverstanden.
Wenn ich mit der obigen Version noch testen soll oder sonst Infos liefern kann, dann darfst Du das gerne mitteilen. Habe aber nur TCM-Transceiver. Ich würde -falls gewünscht- noch User von RS-232-Wandlern direkt ansprechen.
Mir ist momentan leider überhaupt nicht klar, was offen ist? Es wäre nett, wenn Du meine Verwirrung klären könntest. Danke.
Viele Grüße, Christian
Hier meine Arbeitsversionen mit
- Behebung Log3 Fehler
- Abfrage, ob DevIo_OpenDev "disconnected" liefert
- Alternative (deaktiviert) zur Abfrage if($hash->{STATE} eq "disconnected");
In der Arbeitsversion sind eine Vielzahl von anderen Änderungen und Neuerungen enthalten, die aber teilweise noch nicht fertig sind. Bitte TCM und EnOcean gleichzeitig ersetzen.
Zu testen sind ob:
- die vorgeschlagene Änderung einen Systemstart bei entferntem TCM310-Transceiver und vorhandenem Device-Eintrag ermöglicht
- Systeme mit RS484/RS232-Wandlern problemlos arbeiten
Bitte die Ergebnisse so dokumentieren, das Rudi erkennen kann, ob die DevIo-Routinen weiterhin auch problemlos funktionieren. Ich kann das nicht beurteilen.
Danke Klaus für Deine schnelle Reaktion.
Bei meinen Schnelltest seit heute morgen konnte ich bisher keine Probleme mit Deinen Arbeitsversionen und dem USB300 feststellen.
Testumgebungen:
- Fritzbox 7390 (Produktivsystem) mit EnOcean, 2xserielle-Stromzähler , HMLAN, RFXTRX mit umfangreicher fhem.cfg
- Raspi B+ (Testsystem) mit EnOcean, ZWave mit Kurz-fhem.cfg (TCM, ZWave-Stick, Zwavesensor)
Habe getestet jeweils: Neustart mit/ohne USB300 mit Funktionsprüfung; Abziehen und Anstecken während laufendem Betrieb mit Funktionsprüfung
Falls im weiteren Betrieb sich wider Erwarten Probleme zeigen, melde ich mich.
Da mir nicht bekannt ist, was für die DevIo-Routinentests zu beachten ist, habe ich im Anhang mal das Log mit verbose 5 vom Testsystem (Start mit TCM, Abziehen TCM, Wiederanstecken TCM, Start ohne TCM) angehängt. Ist aber umfangreich; wenn ich etwas anderes liefern soll, bitte ich um Info.
Gruß, Christian
Im LOG kann ich auf die Schnelle nicht erkennen, welche Ausgaben zu welcher Konstellation gehören. Wurden die Tests mit den bereitgestellten Dateien ohne die vorgeschlagene Änderung
- Alternative (deaktiviert) zur Abfrage if($hash->{STATE} eq "disconnected");
gemacht?
Falls ja, dann scheint die Abfrage, ob DevIo_OpenDev "disconnected" liefert, zu helfen, die Rudi vorgeschlagen hatte.
Habe die von Dir angehängten Modul-Dateien ohne irgendwelche Änderungen bei mir eingebunden. Dachte Alternative ist nur für den Notfall drin und hab es deshalb nicht ausprobiert. Falsch?
Soll ich das Log aufschlüsseln?
Ok, dann scheint der Vorschlag von Rudi zu helfen. Jedenfalls bleibt wohl in Deiner Konstellation Fhem nicht mehr stehen. Warten wir, ob noch jemand mit RS485/RS232-Wandler testet.
Ich würde die Änderung dann übernehmen. Ein ergänztes LOG benötige ich augenblicklich nicht.
@klaus.schauer
Da ich diesen Thread angefangen habe, erlaube ich mir noch eine Bemerkung anzubringen.
Wenn Du auf eq "disconnected" prüfst, gehst Du von der Annahme aus, dass zur Zeit der Prüfung $hash->{STATE) entweder gleich "opened" oder "disconnected" ist. Dies ist jedoch nicht sicher. Beim oberen Fall war $hash->{STATE} = "initialized" und dies hat das Problem verursacht.
Wenn in Zukunft aus einem unerwarteten Grund beispielsweise $hash->{STATE} = "foobar" ist, hast Du wieder ein Problem.
Deshalb mein Vorschlag auf ne "opened" testen, siehe auch "defensive programming".
ZitatWarten wir, ob noch jemand mit RS485/RS232-Wandler testet.
Habe mir bekannte Nutzer direkt angesprochen. Mal schauen, ob sich wer meldet...
@klaus.schauer: Habe Rückmeldung von einem User mit Eltako FGW14 RS484-RS232 Gateway per PM erhalten. Demnach hat er keine Probleme mit Deiner Arbeitsfassung feststellen können. Er hat sich nur über die zusätzlichen Log-Einträge gewundert, was ja Deiner Arbeitsfassung geschuldet ist...
Ab 08.09.2014 steht ein geändertes Modul 00_TCM per update zur Verfügung.