Du kannst über die LinHK sogar per WLan parametrieren.
Aber wenn es geht dann ist ja alles gut.
Siebo
Gesendet von meinem SM-A530F mit Tapatalk
Statistik: Verfasst von obeis — So 25. Okt 2020, 13:54
]]>
Boris
Statistik: Verfasst von reinholdtb — Sa 24. Okt 2020, 13:03
]]>
Die virtuellen Module können ausschließlich mit LCN-PRO über LinHK parametriert werden.Ich wollte dieses in LCN Pro parametrieren (geht das?)
Ein unparametriertes reales oder virtuelles Modul (also noch ohne eigene Modul-ID) hat zunächst die technische Modul-ID 255, die Meldungen sind also nicht ganz abwegig.
Allerdings lässt sich so leider schlecht sagen, was hier genau falsch läuft. Vielleicht hattest Du dem virtuellen Modul bereits mal eine ID gegeben, dies jedoch nicht in der LP3-Datei der LCN-PRO abgespeichert. Oder es gibt andere Probleme von Seiten LinHK, die dann aber in der LinHK-Protokolldatei stehen und bei Bedarf gerne im internen LinHK-Supportbereich weiter besprochen sollten (führt im Einsteiger-Bereich m.E. etwas zu weit).
Schöne Grüße
Niko
Statistik: Verfasst von Niko — Fr 23. Okt 2020, 15:02
]]>
1) Fehlg. Modul mit Sn 1BFxxxxxx?: Programm ID 250
2) Fehlg. Modul 255 Sn 1BFxxxxxx?: Modul in Programmiermodus versetzt
3) Fehlg. Modul 255 Sn 1BFxxxxxx?: Programmiermodus verlassen (speichern)
Warum Modul 255? Oder was könnte der Fehler sein?
LG
Boris
Statistik: Verfasst von reinholdtb — Fr 23. Okt 2020, 13:03
]]>
Wie sieht es mit der LinHK aus, sendet die ebenfalls (eine NTP-Zeit o.ä.) in den Bus?
So ungefragt macht LinHK das natürlich nicht, Du kannst aber ein in der LinHK-Installation mitlaufendes virtuelles Modul dafür nutzen, regelmäßig ein Zeitsignal in den Bus zu senden. Eine Beschreibung zur Parametrierung findest Du in der mitgelieferten Dokumentation zu den virtuellen Modulen im Abschnitt "Senden einer Systemzeit in den Bus".Schöne Grüße
Niko
Statistik: Verfasst von Niko — Mi 21. Okt 2020, 08:08
]]>
Grüße vom Bodensee
Boris
Statistik: Verfasst von reinholdtb — Di 20. Okt 2020, 18:25
]]>
nachdem das Problem gestern nun wieder auftrat habe "ich nach Hause telefoniert" - die mehrfach geäußerte Vermutung mit den 60Hz war richtig. Ich hab das mit dem Frequenz programmieren also entweder nicht richtig gemacht oder das Modul wollte nicht mitspielen, nach einem weiteren Versuch gestern gings dann, Uhrzeit mit NTP Qual 63 drauf und seitdem ist Ruhe und beide senden brav die korrekte Zeit.
Hier noch zwei Tipps die ich gelernt habe:
1) Diagnose des 60Hz Problems: Das Modul tickt logischerweise um genau die 10% langsamer die "fehlen", daher kann man das einfach nachrechnen: zwei Zeitupdates des fraglichen Moduls suchen, Differenz des Zeitstempel laut Busprotokoll und Differenz des gezeigten Status Kommandos ausrechnen: Die Abweichung zwischen den Beiden beträgt (mehr oder weniger) genau 20%.
2) Der NTP Knopf: Neben dem Fenster für die NTP Zeit sind zwei Pfeile mit denen man die Stunde anpassen kann - ist zwar etwas dämlich weil man es jedes Mal machen muss aber es hilft.
Oli
Statistik: Verfasst von oliwel — Mi 6. Mär 2013, 09:14
]]>
ich hab die Module nun kurz vom Netz getrennt, jetzt senden sie brav wieder mit Prio < 50 die korrekte Zeit. Eine echte Lösung für echte Installationen ist das aber auch nicht. Der WAF leidet sicher drunter wenn ich alle Woche das Haus einmal dunkel machen muss um die Zeit neu zu setzen
Oli
Statistik: Verfasst von oliwel — So 24. Feb 2013, 14:41
]]>
Total tolle Grüße
Uwe
Statistik: Verfasst von Uwe — So 24. Feb 2013, 13:39
]]>
da war ich schneller als die Hotline - habe nun alle drei Module (da ist noch ein M7 drin) neu programmiert - mit dem total tollen Ergebnis dass sich nun alle über die falsche Zeit einig sind:
Code:
13:15:24:361 - M006 StatusG Thu Feb 21 14:49:49 2013 (Quelle=1,Qual=70)13:15:48:090 - M005 StatusG Thu Feb 21 14:49:46 2013 (Quelle=1,Qual=73)Oli
PS: Ich werde mir sicherlich vM zulegen, wollte damit aber bis zum Aufbau der "echten" Anlage warten.
Statistik: Verfasst von oliwel — So 24. Feb 2013, 13:22
]]>
Von der Überzeugung hat das Demo-VM ja sein Können gezeigt. Könnte das ein Kaufargument werden?
Das Domiq-Base aktualisiert übrigens ebenso 'schön' - und das per RTC auch ohne Internetverbindung.
Grüße, Uwe - dem auf Baustellen (noch ohne Internet) immer die NTP-Zeit fehlt
Statistik: Verfasst von Uwe — So 24. Feb 2013, 12:27
]]>
aktuell sind in der Pro wieder die Standardwerte drin, also 50 und 63 wie auf deinem Bild. Wie man am Threadanfang sieht, hatte ich damals die falsche Zeit schon mit Prio 60 auf dem Bus und hatte dafür kurzzeitig dann die manuelle Prio auf 62 gesetzt. Bis vor meinem Urlaub lief die LinHK mit dem virtuellen Modul zum NTP Sync (da ist mir aber jetzt die Testlizenz von dir abgelaufen).
Was grad eigentartig ist - das Modul 5 hat um 19:24 gestern abend das letzte Mal seine Zeit gesendet, seitdem sehe ich nur noch die Zeit vom M6, die geht aber auch ein paar Sekunden nach und läßt sich nicht korrigieren:
Code:
10:45:07:280 - LPRO StatusL Sun Feb 24 10:45:06 2013 (Quelle=2,Qual=50)10:45:13:078 - M006 StatusG Sun Feb 24 10:45:17 2013 (Quelle=1,Qual=73)Code:
10:47:56:446 - M005 StatusG Thu Feb 21 12:46:34 2013 (Quelle=1,Qual=73)Statistik: Verfasst von oliwel — So 24. Feb 2013, 10:49
]]>
[img]1[/img]
Grüße, Uwe - der Modul 5 mal löschen und neu programmieren würde
Statistik: Verfasst von Uwe — So 24. Feb 2013, 01:42
]]>
auch wenn der Thread schon alt ist muss ich diesen nochmal zum Leben erwecken
Meine Bus-Zeit ist schon wieder komplett aus dem Ruder:
Code:
17:24:10:916 - M006 StatusG Sat Feb 23 17:24:03 2013 (Quelle=1,Qual=73)17:24:33:336 - M005 StatusG Wed Feb 20 22:17:01 2013 (Quelle=1,Qual=74)Oli
Statistik: Verfasst von oliwel — Sa 23. Feb 2013, 17:27
]]>
in die vM Doku hab ich natürlich nicht geschaut - ich hatte versucht das über ein Kommando einzukippen. Mir fällt auch grad auf, das wir hier im falschen Forum für Details sind
Aber danke für den wink, dann werd ich mir wohl mal eine Lizenz dafür organiseren.
Oli
Statistik: Verfasst von oliwel — Sa 12. Jan 2013, 23:33
]]>