Unbekanntes device, oder?

Begonnen von franky08, 07 Juni 2014, 00:33:07

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: martinp876 am 08 Juni 2014, 15:06:32
genau - die sind in CUL_HM nicht definiert. Die müsste man suche gehen.

Events gehen nicht verloren, nicht mehr also vorher. Wenn die Quelle nicht bekannt ist wurde die message schon immer verworfen - nur eben geräuschlos. Das ist jetzt nicht mehr der Fall. CUL_HM sagt, es kennt die Quelle nicht.

Wenn das stimmen würde, dürfte doch überhaupt keine Kommunikation stattfinden, denn entweder CUL_HM kennt 127000 (dann funktioniert alles) oder CUL_HM kennt 127000 nicht (dann müssten alle Messages verlorengehen).

Es ist doch absolut unverständlich, dass CUL_HM die ID "manchmal" kennt - denn bisher wurde doch die ID immer korrekt verarbeitet und das kann ja nach Deinen Ausführungen nur stattfinden, wenn die ID bekannt ist.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

franky08

Ich hab den HMUSB jetzt aus dem System geschmissen und die betreffenden Device mit dem HMLAN gepaird.

VG
Frank
Debian Wheezy auf ZBOX nano/ Debian Bullseye auf 2.ter ZBOX nano F2F an 2x RaspiB
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu ,fhem5.8, CCU2,
ECMD an AVR-NET-IO mit DAC u. ADC an Junkers Stetigregelung, Siemens LOGO!8, JeeLink uvm...

betateilchen

Das sollte eigentlich doch egal sein, weil sowohl der HMUSB als auch HMLAN über das Modul 00_HMLAN eingebunden werden und dieses Modul überhaupt nicht weiss, welche Hardware letztendlich angesprochen wird.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

martinp876

so - mal sehen ob ich alles habe:

ZitatDieser Aussage muss ich vehement widersprechen. Ich hatte bisher noch nie den Effekt, dass das Öffnen einer Tür oder eines Fensters nicht von fhem registriert wurde. Das hatte ich gestern/vorgestern zum ersten Mal erlebt.
Nachrichten mit src-ID unbekannter devices sind schon seeehr lange verworfen worden. Die Abfrage ist immer noch identisch. Die Auswirkung ist jetzt anders, jetzt gibt es einen LOG Eintrag.
Wenn ein reading fehlt hat es einen anderen Grund. Müssen wir suchen.
Welches Reading war es?

ZitatWie wäre es mit einer Variante d)
d) CUL_HM erfährt automatisch die HMID eines Devices, das per 00_HMLAN definiert wird.
das ist auch meine Idee - im Prinzip
A) das reicht nicht. Auch die CUL ist zu berücksichtigen. Da reicht die Definition  nicht, erst der RF mode, also ein Attribut muss erkannt werden.
B) auch das Löschen müsste erkannt werden. Alles was automatisch eingerichtet wird sollte auch wieder so verschwinden
C) es zu merken ist der eine Teil. Dann muss es gemerkt werden - also ein Device definiert werden in CUL_HM. Das ist dann die vccu.
D) ein Device in CUL kann erst definiert werden, wenn es eine HMId hat. Die Vergabe gehört eigentich nach CUL_HM, also eine Aktion der vccu.
>> wie immer steckt der Teufel im Detail. Die Historie der Definitionen müsste aufgebrochen werden.
=> bis auf den Automatismus existiert es schon. Den würde ich gerne noch einbauen. Bei HMLAN werde iches wohl machen - ich denke es wird keinen aus der Bahn werfen. Bei CUL muss ich es Rudi beibringen.

Zitatkann man machen (hab ich grade gemacht!), hilft aber nix:
2014.06.08 15:37:59 3: az_HMUSB: Unknown code A09998112999999000001::-69:az_HMUSB, help me!
ok, das ist mein Problem/fehler. Das werde ich beheben. Das sind die messages, welche den Zustand eines HMLAN/USB nach reconnect erfassen. Die muss ich unterdrücken, weil sie hausgemacht sind. Die messages habe keinen Inhalt.
Die anderen - wie vorher gemeldet -  sollten aber nicht mehr kommen


ZitatWenn das stimmen würde, dürfte doch überhaupt keine Kommunikation stattfinden, denn entweder CUL_HM kennt 127000 (dann funktioniert alles) oder CUL_HM kennt 127000 nicht (dann müssten alle Messages verlorengehen).
127000 als src-ID bei empfangenen nachrichten ist eher selten. gesendete src-id ist etwas anderes.
127000 bei Empfangenen Nachrichten als dest-id ist ein anderes event, genau wie die Senderichtung.
ist schon korrekt so.

ZitatEs ist doch absolut unverständlich, dass CUL_HM die ID "manchmal" kennt - denn bisher wurde doch die ID immer korrekt verarbeitet und das kann ja nach Deinen Ausführungen nur stattfinden, wenn die ID bekannt ist.
genau hinsehen, wie und wo. Sender ist nicht parser. Es wird alles geparst wie vor. Nur der Log ist "neu".

ZitatIch hab den HMUSB jetzt aus dem System geschmissen und die betreffenden Device mit dem HMLAN gepaird.
ein sauberes Vorgehen mit mehreren IOs ist, die ID in CUL_HM bekannt zu machen. Wenn du nur eine ID hast für beide IOs reicht eine vccu. Wenn es 2 verschiedene IDs sind, brauchst du 2.
Zu empfehlen ist dann, die IOs auch der vccu anzugliedern.
Wenn du nur noch ein IO hast wirst du das event nicht sehen. Es handelt sich ja ausschliesslich un die messages, die von der Zentrale gesendet werden. Ein 2. IO wird diese Nachrichten empfangen und in den Parser senden. Wenn du nur ein IO hast, passiert das nicht, klar. Also auch keine entsprechende message.

Gruss Martin



Deudi

Moin,

ich hatte auch sackweise die Einträge im Log und bin dann auf eine ältere Version zurück gegangen. Ich habe 3 HMLAN mit unterschiedlichen IDs. Das müllt einem das Log zu, obwohl das jetzt "normal" ist?

Eigentlich wollte ich ja irgendwann auf eine ID umstellen. Wenn ich das richtig verstanden habe, sollte ich eine VCCU einrichten und dann bekomme ich eine Redundanz nicht nur beim Empfang, sondern auch beim Senden, da die VCCU bei Ausfall eines HMLAN auf ein anderes ausweicht. Ausserdem sind die ganzen Meldungen dann weg.
Wie gehe ich da vor? In der commandref finde ich nix.

Grüße
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

betateilchen

Zitat von: martinp876 am 08 Juni 2014, 21:25:03
ok, das ist mein Problem/fehler. Das werde ich beheben. Das sind die messages, welche den Zustand eines HMLAN/USB nach reconnect erfassen. Die muss ich unterdrücken, weil sie hausgemacht sind. Die messages habe keinen Inhalt.
Die anderen - wie vorher gemeldet -  sollten aber nicht mehr kommen

ja, sieht erstmal so aus.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rolf

Habe zwei HMLAN-Adapter mit gleicher ID, d.h. seit dem Update auch das Problem.
Scheitere augenblicklich daran eine VCCU einzurichten, sprich ich weiss einfach nicht wie es geht.
Hab bisher auch nirgends einen Info gefunden wie man so eine VCCU einrichtet - hat mir bitte jemand einen Tip, danke vorab.
System 1: Intel NUC (ubuntu 18.04.1 lts) mit diversen Homematic-Komponenten + CUNO mit Uniroll/Hoermann + RFXTRX mit TFA + EnOcean mit Eltako + Alexa + Harmony + per HMCCU gekoppelter PI3-Raspberrymatic mit HM-IP-Komponenten
System 2: PI2-Raspberry (Jessie) + Signalduino mit Somfy/RTS

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rolf

System 1: Intel NUC (ubuntu 18.04.1 lts) mit diversen Homematic-Komponenten + CUNO mit Uniroll/Hoermann + RFXTRX mit TFA + EnOcean mit Eltako + Alexa + Harmony + per HMCCU gekoppelter PI3-Raspberrymatic mit HM-IP-Komponenten
System 2: PI2-Raspberry (Jessie) + Signalduino mit Somfy/RTS

rolf

Mit einer definierten VCCU funktioniert bei mir mit zwei HMLAN-Adaptern mit gleiche HMiD wieder alles problemlos - Danke nochmal !  ;D
System 1: Intel NUC (ubuntu 18.04.1 lts) mit diversen Homematic-Komponenten + CUNO mit Uniroll/Hoermann + RFXTRX mit TFA + EnOcean mit Eltako + Alexa + Harmony + per HMCCU gekoppelter PI3-Raspberrymatic mit HM-IP-Komponenten
System 2: PI2-Raspberry (Jessie) + Signalduino mit Somfy/RTS

Steffen

Hallo!

Habe nur 1 HMLAN und habe trotzdem diese Fehler meldung:
Zitat2014.06.09 20:19:17 3: HMLAN1: Unknown code A0ED18202193B68193858010100003B::-53:HMLAN1, help me!

Gibt es dafür schon eine Lösung die hier übersehen habe??

Mfg Steffen

betateilchen

Es kommt nicht auf die Anzahl der HMLAN an. Die Lösung ist auch für Dich: Definiere eine vccu.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Steffen

Zitat von: betateilchen am 09 Juni 2014, 20:31:44
Es kommt nicht auf die Anzahl der HMLAN an. Die Lösung ist auch für Dich: Definiere eine vccu.

Ok Danke werde es später mal versuchen, obwohl ich ja noch nicht ganz verstanden habe warum ich auf einmal eine vccu definieren muss?!

Mfg Steffen

betateilchen

Zitat von: Steffen am 09 Juni 2014, 21:07:18
obwohl ich ja noch nicht ganz verstanden habe warum ich auf einmal eine vccu definieren muss?!

Lies einfach diesen Thread noch einmal von Anfang an :) Martin hat versucht, es zu erklären.

kurz gefaßt: das ist jetzt einfach so, leg die vccu einfach an und gut.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

ZitatDie Lösung ist auch für Dich: Definiere eine vccu.
und für mich?  ;D
Ich habe eine vccu und trotzdem folgende (seltene) Meldungen:
hmusb: Unknown code A09998112999999000001::-28:hmusb, help me!


Die Meldung kommt einmal jedesmal kurz (ca. 15 Sekunden nach dem Trigger global:INITIALIZED) nach dem Restart von FHEM.

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy