Hallo,
eigentlich bin ich kein Anfänger, denn ich habe schon seit Jahren eine FHEM Installation laufen mit hauptsächlich HM-Komponenten, etwas von FS20 und Rademacher für Rollladen. Leider ist dies System sehr veraltet und noch auf dem Stand 5.6.. FHEM arbeitet dort über eine VCCU mit zwei HMLAN (VCCU und beide HMLANs haben dieselbe gesetzte HMID), FS20 mit einem Funkmodul auf dem Raspi, Rademacher mit USB-Stick, HUE-Bridge zur Anbindung von Alexa auf einem separaten Raspi. Beide RPi, HMLANs haben feste IP-Adressen. Die Integration einer CCU2 als Funkgateway hat auf dem alten System nicht geklappt. Deshalb habe ich 2 umprogrammierte CCUs auch verfügbar für das neue System.
Ja ich bin selber Schuld, dass ich dies nicht mehr sinnvoll updaten kann, da sich 6.0 weit von 5.6. entfernt hat und auch das Wheezy nicht mehr updatefähig ist. Ich gehe auch davon aus, dass ich nicht umhin komme, alle Geräte von Hand im neuen FHEM anzulernen.
Ich habe einen neuen RPi3 aufgesetzt mit Buster lite und FHEM 6.0. Da sind schon etliche Kalender, Pushover und telegramBot drauf und so ein "Hintergrund"-Kram.
So, nun meine eigentliche "Anfängerfrage":
Voraussetzung: das alte System läuft bei allen nun folgenden Schritten möglichst einfach weiter
1. Ich würde nun zuerst eine VCCU auf dem neuem System installieren und dieser dieselbe HMID geben wie der auf dem alten System.
a) Alternativ besser eine andere HMID vergeben, damit das neue System später insgesamt eine neue HMID für die IO-Geräte nutzt?
2. Ich würde versuchen, die umprogrammierten CCUs als Funkgateway auf dem neuen System zu installieren und diesen dann entweder die alte HMID zu geben oder gemäß 1a die neue HMID.
a) falls das Nutzen der alten HMID auf dem neuen System zu Konflikten mit dem alten laufenden FHEM führt, müsste ich ab diesem Zeitpunkt das alte System ausschalten solange das neue läuft und umgekehrt.
b) falls es keine Konflikte gibt mit zwei parallel in Betrieb befindlichen FHEM-Systemen mit je einer VCCU mit identischen HMIDs, bzw. wenn ich eh besser eine neue HMID nutzen soll, können beide Systeme weiter laufen.
3. Ich würde einen NEUEN HM-Aktor im neuen System anlernen um zu prüfen, ob alles klappt
4. Im alten System trenne ich einen HMLAN vom Stromnetz. Dann kopiere ich die RAW Def dieses HMLAN in eine Textdatei. Dann entferne ich dieses HMLAN aus der config des alten Systems.
a) ich müsste hierfür in allen Devices nachprüfen, ob dieses HMLAN noch als IODev drin steht, zudem muss ich es aus der VCCU "entfernen". Das alte System sollte dann weiterlaufen mit nur einem HMLAN. Möglicherweise können dann einige Geräte nicht mehr erreicht werden wegen der Funkreichweite im Haus.
b) Falls ich im neuen System dieselbe HMID nutzen kann, nehme ich das HMLAN wieder in Betrieb. Dann will ich die alte RAW Definition nutzen und erhoffe mir, dass dieses HMLAN im neuen System mit der VCCU redet und auch den ersten dort angelernten HM-Aktor erreichen kann. Wenn das so klappt, kann ich danach alle alten Geräte im neuen System von Hand an die VCCU anlernen und entsprechend IOGrp setzen.
c) falls ich besser eine neue HMID nutzen soll, muss ich das HMLAN zunächst über die HM-Originalsoftware mit neuen Daten (feste andere IP-Adresse) versorgen und dann ganz normal im neuen System anlernen, die neue HMID setzen und wie unter b) alle alten Geräte umziehen.
Könnte die Variante 4b klappen? wenn ja, dann hätte ich mir das Neu-Programmieren der HMLANs erspart und könnte sogar auf die Einbindung der umprogrammierten CCUs verzichten beim Umzug. ich kann die dann später immer noch als weitere Funk-Gateways im neuen System einbinden.
Ich habe es vielleicht etwas umständlich formuliert, dafür bitte ich um Entschuldigung.
Wenn eurer Rat ist, dass ich einfach ein neues System aufsetze mit neuer HMID und anderen IP-Adressen ist es auch ok....Ich denke, dass ich auf keinen Fall die alte Config in Bezug auf die DEF aller physischen Geräte einfach ins neue System kopieren kann.....es haben sich attr geändert bei den Geräten so weit ich nachgelesen habe....
Vielen Dank im Voraus.
Michael
Zitat aus dem alten Thread
Zitat von: Otto123 am 05 Dezember 2020, 18:04:08
Du hast also schon begonnen:Dann mach weiter :)
"klemm" doch mal einen HMLAN um und schau was passiert? hast Du auf dem alten System eine VCCU oder haben beide HMLANs die gleiche hmId?
Dann fang mit der VCCU an, dazu brauchst Du nichts außer die hmId.
Dann im alten System den HMLAN auf close setzen (oder zur Sicherheit im Attribute auf dummy 1)
im neuen System definieren und in die VCCU einbinden.
mit der RAW Def beschäftigen - wenn nicht schon geschehen.
Dann einen Aktor per hmPairSerial (vom alten System) anlernen - keine Angst da passiert nichts!
usw...
Es gibt keinen Grund eine neue hmId zu verwenden!
Der zeitweise / testweise Parallelbetrieb führt u.U zu ein paar Eigenheiten:
Es können attack Meldungen auftreten
Anlernen mit beiden Systemen aktiv wird nicht gut funktionieren. Also da immer das andere System den HMLAN auf close setzen.
Anlernen mit hmPairSerial bei existierendem Pairing ist kein Anlernen im eigentlichen Sinne, es ist ein eleganter Weg die Anlern Nachricht vom Gerät abzufordern ohne Knöpfchen drücken. ;)
https://heinz-otto.blogspot.com/2016/12/in-fhem-ein-homematic-gerat-neu-anlegen.html
Gruß Otto
Hallo,
das sehe ich etwas anders, habe selber schon Raspi über größere Distanzen hochgezogen.
Ich würde mal die SD-Karte sicher und dann den Versuch machen.
Sowas hilft auch bei späteren Aktionen selbstvertrauen aufzubauen.
https://www.prado.lt/how-to-upgrade-debian-7-wheezy-to-10-buster-safely
Sicher ist ein Neustart immer wieder mal nett, macht aber auch einiges an Arbeit.
Peter
@Otto123
Ja schon begonnen, ja auf dem alten System haben alle VCCU und die beiden HMLAN dieselbe HMID, deinen blog lese ich nachher bzgl. serial anlernen vom alten system weg auf das neue, an dem ich einen alten HMLAN angeklemmt habe...bin gespannt, klar dsss ich beim serial anlernen das verbliebene HMLAN im alten System auf close setzen. ich bin echt gespannt.
Danke.
Also Anle(rn|g)en am neuen System geht auch mit configtaster drücken und dann getConfig - versuch es einfach. Bei den Fernbedienungen und Sensoren musst Du configtaster drücken. Oder Du übernimmst die Konfiguration mit Raw Def, geht ein wenig tricki aber geht schon.
@peteruser
danke für die Anleitung. Ich werde diese auch mal komplett ausführen um zu schauen, dass es auch funktioniert. Auch wenn das blöd klingt beides zu machen, aber ich habe zeit dies mal auszuprobieren und dabei lernt man auch viel.
Danke dafür.
Zitat von: Otto123 am 06 Dezember 2020, 12:33:17
Also Anle(rn|g)en am neuen
@otto
ist das komische Schreiben von Anlerngen ein Schreibfehler? oder ein Befehl den ich nicht gefunden habe bisher.
Ja mein Wunsch ist es, so viel wie möglich ohne Knöpfchen drücken zu machen, Fernbedienungen habe ich nicht, allerdings einige Sensoren für Türen und diverse batteriebetriebenen Taster und an den Rauchmeldern separate Funktaster, die es mir ermöglichen von außen über die anliegende 5V einen extern weitergeleiteten Rauchalarm der anderen Rauchmelder zu simulieren. So kann ich bisher über einen SET an das Rauchmelderteam alle Rauchmelder laut werden lassen, sobald bei aktivierter Alarmanlage eine Tür geöffnet wird. Und sechs Rauchmelder plus die zusätzlichen beiden Sirenen machen einen ohrenbetäubenden Lärm. Das externe Lautwerdenlassen der Rauchmelder über Funk geht ja nicht mehr, aber als 5V Eingangssignal an den Klemmen klappt. Und die Rauchmelder die an den Decken kleben haben diese externe Alarmierung nicht sondern arbeiten vorschriftsmäßig als Rauchmelder und melden einen echten Alarm halt nur an das Team im FHEM.
Zitat von: Peteruser am 06 Dezember 2020, 00:11:57
Hallo,
das sehe ich etwas anders, habe selber schon Raspi über größere Distanzen hochgezogen.
Ich würde mal die SD-Karte sicher und dann den Versuch machen.
Sowas hilft auch bei späteren Aktionen selbstvertrauen aufzubauen.
https://www.prado.lt/how-to-upgrade-debian-7-wheezy-to-10-buster-safely
Sicher ist ein Neustart immer wieder mal nett, macht aber auch einiges an Arbeit.
Peter
Für jemanden der das schon öfter (u.U. auch "remote") gemacht hat ist ein Upgrade sicher "einfacher"/schneller...
Wobei selbst das (also schneller) glaube ich nicht...
Ein Raspbian ist null komma nix geflasht.
Basiseinrichtung dauert auch nicht wirklich...
fhem Installation (the easy way) dauert unter 5min...
Weitere notwendige Pakete einspielen, Backup einspielen und fertig...
Dauert bei mir deutlich unter 1h
Und dann ist das System neu, sauber und frisch :)
Weil bei diesem "running Upgrade" z.B. nicht von initd auf systemd umgestellt wird...
...weil initd ja noch unterstützt wird, was wenn nicht mehr?
Wenn beim Ändern der Paketquellen etwas schief geht?
Wenn beim Upgrade etwas schief geht und der Paketinstaller "durcheinander" ist...
Wenn...
Dann: ist ein "Newbee" / Linux-unkundiger "am Ende"...
Und: muss trotzdem neu anfangen...
Wo ist da der Zeit-Vorteil... ;)
Und man hat trotzdem (in Teilen) ein (ver)altetes System...
Aber das nur meine Meinung zu dem Thema...
Und: ein Neu-Aufsetzen prüft/schult auch die (hoffentlich vorhandene) Backup-/Restore-Strategie!
Weil bei mir ist ein Umzug egal ob selbes OS, selbe Plattform oder ganz woanders hin nichts anderes wie ein Restore... :)
Gruß, Joachim
Heute ist Nikolaus ;D, das war der erbärmliche Versuch Anlegen und Anlernen in ein Wort zu schreiben ;)
Du simulierst ja ein Anlernen, dabei wird aber eigentlich die hmId der Zentrale ins Gerät geschrieben. Die steht aber schon drin. Deswegen ist es zwar der Anlernvorgang aber im ungefährlichen Sinne nur ein Anlegen.
Du kannst wie gesagt die Definitionen aus der alten Installation per raw Def kopieren, leicht abändern (etwas weglöschen) und im neuen System in der Raw Def wieder einwerfen. Ich such mal den Artikel dazu.
Der hier war der ursprüngliche
https://forum.fhem.de/index.php/topic,103344.0.html
Ob sich am aktuellen Stand was geändert hat weiß ich nicht mehr genau :-[
Hallo Otto,
ich habe als Beispiel die RAW für einen normalen Schaltaktor hier reinkopiert. Ich habe in dem von dir verlinkten Artikel folgendes verstanden:
Zuerst lege ich händisch dieses Gerät über eine Raw.definition an, sprich alle Einträge aus RAW in die FHEM Kommandozeile als Ganzes reinkopieren und ausführen. Das Gerät existiert ja noch nicht im neuen FHEM. Vorher muss ich aber einige Einträge löschen, weil die so nicht mehr möglich sind.
defmod Kueche_LED CUL_HM 377770
attr Kueche_LED IODev HMLAN2 #hier trage ich das im neuen System vorhandene HMLAN ein
attr Kueche_LED IOgrp VCCU # dies bleibt so
attr Kueche_LED autoReadReg 4_reqStatus #bleibt oder auf 2 setzen wegen des Funkverkehrs?
attr Kueche_LED expert 2_full #bleibt
attr Kueche_LED firmware 2.3 #vermute dass das bleiben kann
attr Kueche_LED group Licht # kann bleiben, da dann die grp Licht angelegt wird
attr Kueche_LED model HM-LC-Sw1PBU-FM # dies soll gelöscht werden, richtig? oder mit dem Force-befehl setzen?
attr Kueche_LED peerIDs 00000000, # Gerät hatte nie einen peer, kann also bleiben und stört nicht
attr Kueche_LED room Kueche,CUL_HM #kann bleiben, legt die Räume an
attr Kueche_LED serialNr MEQ0328910 #kann bleiben
attr Kueche_LED subType switch # muss gelöscht werden?
attr Kueche_LED webCmd on:off # kann bleiben
setstate Kueche_LED on
setstate Kueche_LED 2015-08-03 18:14:43 .D-devInfo 010100
setstate Kueche_LED 2015-08-03 18:14:43 .D-stc 10
setstate Kueche_LED 2015-08-03 18:14:48 .R-intKeyVisib invisib
setstate Kueche_LED 2018-08-10 12:10:12 .R-localResDis off
setstate Kueche_LED 2018-08-10 12:10:13 .R-statusInfoMinDly 2 s
setstate Kueche_LED 2018-08-10 12:10:13 .R-statusInfoRandom 1 s
setstate Kueche_LED 2018-08-10 12:10:13 .R-transmitTryMax 6
setstate Kueche_LED 2018-12-09 08:01:23 .peerListRDate 2018-12-09 08:01:23
setstate Kueche_LED 2020-12-06 11:59:44 .protLastRcv 2020-12-06 11:59:44
setstate Kueche_LED 2020-12-06 11:59:44 CommandAccepted yes
setstate Kueche_LED 2015-08-03 18:14:43 D-firmware 2.3
setstate Kueche_LED 2015-08-03 18:14:43 D-serialNr MEQ0328910
setstate Kueche_LED 2018-12-09 08:01:21 PairedTo 0xAAAAAA # hier steht in echt eine andere HMID
setstate Kueche_LED 2015-08-03 18:14:48 R-pairCentral 0xAAAAAA #hier steht in echt eine andere HMID
setstate Kueche_LED 2015-08-03 18:14:49 R-sign off
setstate Kueche_LED 2018-12-09 08:01:21 RegL_00. 02:01 0A:AA 0B:AA 0C:AA 15:FF 18:00 00:00
setstate Kueche_LED 2018-12-09 08:01:22 RegL_01. 08:00 30:06 57:24 00:00
setstate Kueche_LED 2020-12-06 11:59:44 deviceMsg on (to VCCU)
setstate Kueche_LED 2020-12-06 11:59:44 level 100
setstate Kueche_LED 2020-12-06 11:59:44 pct 100
setstate Kueche_LED 2018-12-09 07:18:39 powerOn 2018-12-09 07:18:39
setstate Kueche_LED 2020-12-06 11:59:44 recentStateType ack
setstate Kueche_LED 2020-12-06 11:59:44 state on
setstate Kueche_LED 2020-12-06 11:59:44 timedOn off
die setstate würde ich alle so lassen, insbesondere das paired to 0xAAAAAA (AAAAAA ist ein fiktives Beispiel, das neue System hat in der vccu und dem HMLAN auch diese fiktive AAAAAA HMID).
Dann habe ich verstanden, dass ich in der VCCU ein HMpairserial auslöse in der Kommandozeile über diesen Befehl
set <Name des IO-Device> hmPairSerial <10-stellige Seriennummer>
oder über die Buttons auf der VCCU Definitionsseite im FHEM. Die 10-stellige Seriennummer des Aktors kenne ich ja aus der RAW Def. Am Ende sollte damit der Aktor quasi umgehängt worden sein an das HMLAN (welches sogar das alte sein kann, welches ich im neuen System eingerichtet habe) und nur noch im neuen System integriert sein. Die Verbindung des Aktors im alten System zum dort noch vorhandenen HMLAN geht von allein verloren, oder?
Entweder kann das Gerät dann direkt steuern oder einmal get config ohne Knopf drücken machen.
Alles richtig so?
Danke im Voraus.
Michael
Zum ersten: wir reden immer von der Raw Definition https://wiki.fhem.de/wiki/Import_von_Code_Snippets
Die Verbindung zwischen Zentrale und HM Gerät besteht nur in der hmId - also hast Du zwei Zentralen mit der gleichen hmId, dann erkennt das Gerät beide Zentralen quasi als Eine.
Bei dem Vorgehen über das wir reden wird nicht wirklich angelernt und abgelernt.
Du kannst aus beiden Zentralen steuern.
Auf Grund der Eigenheit des Moduls CUL_HM kannst Du nicht einfach die Definition von der alten Installation nehmen und in der neuen genauso ausführen. Du musst vorher wie beschrieben ein paar Dinge einfach weglassen, die entstehen im neuen System von allein wieder. Es wird auch neue Dinge im neuen System geben, da eine Weiterentwicklung stattgefunden hat.
Gruß Otto
Zitat von: Otto123 am 06 Dezember 2020, 21:50:02
Zum ersten: wir reden immer von der Raw Definition https://wiki.fhem.de/wiki/Import_von_Code_Snippets
Das habe ich gelesen, wobei es für mich als Leser kompliziert beschrieben ist wie man das konkret anwendet. Das im Link angelegte Import dummy dient dazu, selbst in ein bestehendes echtes Gerät importiert zu werden. Danach ist das echte Gerät als dummy definiert? Ich würde es besser verstehen wenn ich in dieses Import dummy die Einträge aus dem echten Gerät eintrage. Das hin- und herschieben eines Gerätes zwischen zwei parallel laufenden Systemen entspricht schon sehr genau meinem Erfordernis. Mein altes System wäre quasi das Testsystem aus dem ich nun ein Gerät in das neue Produktivsystem dauerhaft verschiebe.
Die Verbindung zwischen Zentrale und HM Gerät besteht nur in der hmId - also hast Du zwei Zentralen mit der gleichen hmId, dann erkennt das Gerät beide Zentralen quasi als Eine.
Ja ich habe ja auf dem alten und dem neuen System je eine VCCU mit identischer HMID. Wenn das HMLAN auf dem neuen System connected wäre (siehe mein anderer Beitrag bzgl. Disconnect der zum HMLAN umprogrammierten CCU2 im neuen System). Noch habe ich keines der beiden HMLANs aus dem alten System ins neue System übertragen. Das mache ich wenn die umprogrammierten CCUs nicht connected werden können.
Bei dem Vorgehen über das wir reden wird nicht wirklich angelernt und abgelernt.
Ja das hatte ich verstanden, denn ich paire ja nicht über das Knöpfchrn sondern gaukel dem Aktor bzw. Sensor nur vor, dass es wieder über die HMID mildem zuständigen IODev redet.
Du kannst aus beiden Zentralen steuern.
Genau das will ich ja versuchen sobald die blöde CCU2 connected ist.
Auf Grund der Eigenheit des Moduls CUL_HM kannst Du nicht einfach die Definition von der alten Installation nehmen und in der neuen genauso ausführen. Du musst vorher wie beschrieben ein paar Dinge einfach weglassen, die entstehen im neuen System von allein wieder. Es wird auch neue Dinge im neuen System geben, da eine Weiterentwicklung stattgefunden hat.
Ja es passt nicht direkt in die neue Welt, deshalb hatte ich oben die raw def hingeschrieben und das markiert von dem ich glaube, dass das weg muss. Aber ist das alles, was ich anpassen muss?
Import:dummy.
Ich würde also im neuen System das importdummy anlegen und in dessen raw def die Daten aus dem echten Gerät aus dem alten System reinkopieren?
Danke für deine Geduld.
Gruß Otto
Du brauchst normal kein Importgerät! Oben das große Plus neben der Eingabezeile drücken!
Ich meine das reicht:
defmod Kueche_LED CUL_HM 377770
attr Kueche_LED IODev HMLAN2 #hier trage ich das im neuen System vorhandene HMLAN ein
attr Kueche_LED IOgrp VCCU # dies bleibt so
attr Kueche_LED autoReadReg 4_reqStatus #bleibt oder auf 2 setzen wegen des Funkverkehrs?
attr Kueche_LED expert 2_full #bleibt
attr Kueche_LED firmware 2.3 #vermute dass das bleiben kann
attr Kueche_LED group Licht # kann bleiben, da dann die grp Licht angelegt wird
attr Kueche_LED modelForce HM-LC-Sw1PBU-FM # dies soll gelöscht werden, richtig? oder mit dem Force-befehl setzen?
attr Kueche_LED peerIDs 00000000, # Gerät hatte nie einen peer, kann also bleiben und stört nicht
attr Kueche_LED room Kueche,CUL_HM #kann bleiben, legt die Räume an
attr Kueche_LED serialNr MEQ0328910 #kann bleiben
attr Kueche_LED webCmd on:off # kann bleiben
Gruß Otto
Danke Otto
Versuche dann mal sobald ich ein IODev im neuen System habe. Das mit Force hatte ich ja schon vermutet.
Danke für die Durchsicht der raw def.
Hallo Otto,
Der Umzug funktioniert so nicht.
Ich würde mich auch gerne daran beteiligen, die wiki-Eintragung über dieses Import-Dev zu anzupassen, dass man sie nachmachen kann. Insbesondere fehlt mir dort die klare Beschreibung, wie Device von einem Testsystem auf ein Produktivsystem umziehen OHNE Knöpfchen drücken.
Aber zurück zum Umzug.
Ich habe über Chrome das neue System (192.168.a.xx) im webfrontend aufgerufen. Das vorhandene alte System rufe ich über Edge auf (192.168.A.yy). Ich gehe im alten System auf ein vorhandenes Gerät (Türkontakt, CUL_HM 56CADC), gehe dort in die RAW-def und kopiere alle attr Einträge, alle anderen Einträge kopiere ich nicht. Dann gehe ich in das neue System und kopiere den Eintrag in der FHEM Befehlszeile unter Nutzung des + .
Im geöffneten Fenster im neuen System (das Device ist noch nicht da) passe ich die Einträge in der RAW Definition an:
IODev (alt HMLAN1) auf ein im neuen System befindliches IODev (HMLGW1),
IOgrp (alt VCCU) auf eine im neuen System befindliche IOgrp (VCCUneu),
model .... durch modelFroce
Wenn ich dann den execute Befehl im neuen System drücke erscheint die Fehlermeldung dass das HMid CUL_HM 56CADC schon existiert. Dieses Device existiert aber noch gar nicht im neuen System, es sollte ja durch das reine Kopieren der angepassten RAW-Definition erst angelegt erden. Das Anlegen in der Befehlszeile im FHEM klappt so nicht.
Oder muss ich hierfür zwanghaft das IODev (HMLAN1) aus dem alten System vorher ins neue System einbinden?
mach mal ein list DEF=56CADC
Das Gerät wird schon unter anderem Namen existieren, jede Anlernmessage erzeugt sofort dieses Gerät.
Ansonsten poste bitte die kopierte Fehlermeldung damit wir uns nicht missverstehen.
Zwanghaft musst Du gar nichts :)
Hallo Otto,
das Gerät ist tatsächlich im neuen System angelegt worden, obwohl ja diese Meldung im RAW Fenster erscheint:
HMid DEF already used by HM_56CADC
Dies Fenster kann man nur Kenntnis nehmen. Danach kann man das Fenster in der RAW Def schließen. Daraus leite ich (fälschlicherweise) ab, dass das Bekanntmachen (ist ja kein pairing) des Sensors im neuen System NICHT geklappt hat.
Ich hätte anstelle dieser Meldung eine Meldung erwartet, dass das Gerät nun im (neuen) System existiert/eingebunden ist.
Die Status-Meldung des Türkontakts erscheinen auch völlig normal im neuen System, im alten auch weiterhin vorhanden.
Ich mache dann mal weiter. Bin auch gespannt, wie Befehle (DOIF, at, usw.) ins neue System kopiert werden. Das müsste ja problemlos gehen, sobald die darin benutzten Geräte im neuen System bekannt sind.
Danke Dir.
Wenn execute im Raw Def Fenster erfolgreich war steht das explizit da. Bei eine Fehlermeldung (wie bei Dir) wird nicht weitergemacht!. D.H. in einer der Zeilen ist ein Fehler aufgetreten die Folgezeilen werden nicht ausgeführt.
In seltenen Fällen, kann es sein, dass als Erfolgsmeldung ein leeres Fenster mit eine OK Button kommt.
Hallo Otto,
nun ja, die Gerät sind trotz dieser Meldung alle im neuen System angelegt. Sie empfangen State-Änderungen (derzeit alles Türkontakte).
Was kann denn falsch sein, wenn das eine Fehlermeldung ist, die das Abarbeiten des Defmod irgendwie verändert?.
Was ich festgestellt habe ist, dass kein angelegtes Device eine Serialnummer hat und wenn ich die als attr zuordnen will erscheint die Meldung
serialNr illegal for virtual devices
Somit erkennt das neue System die physikalischen Device trotz modelForce nicht als reale Device an.
In den empfangenen Telegrammen wird die Serial mit übertragen, aber das Device wird wohl immer virtual bleiben?
wenn das so ist, kann ich doch kein physikalisches Gerät auf diese Weise umziehen? Oder ändert sich das doch erst wenn das physikalische Device richtig gepairt wird?
Irgendwie klingt das danach, als wären die CUL_HM-Devices im neuen FHEM schon vorhanden, wenn auch unter anderem Namen?
Dann wäre hier ein deviceRename eher angezeigt, und vermutlich kennt dann das neue FHEM auch schon das Model etc.. Einfach mal suchen, was schon da ist:
list TYPE=CUL_HM DEF
So wie ich und Jörg schon gesagt haben:
Wenn ein Gerät (aus welchen Gründen auch immer) eine Anlernnachricht sendet, wird FHEM per Autocreate das Gerät unter seinem Standardnamen anlegen.
Dann kannst Du keine neue Definition mehr per Hand machen. Du kannst die existierende verändern oder die existierende löschen und dann manuell neu machen.
Du hast jetzt tagelang mit deinen IOs rumgespielt, mich wundert es nicht das schon alle Geräte da sind. Aber das sieht man doch? Einfach im Raum CUL_HM schauen.
Der ursprünglich angedachte Weg ist, Du ziehst existierende um. Das wächst sich jetzt für Dich zum Problem aus :'(
Also löschen und neu machen.
Oder umbenennen und wie gesagt die Definition mit defmod drüber bügeln.
welchen vorteil hat eigentlich dieses stückweise rumschaufeln von kleinen portionen der fhem.cfg.
die ganzen device daten fehlen dann ja immer noch.
Hallo Beta-teilchen,
hier der List von VOR dem ersten Übernehmen:
VCCUneu AAAAAA
VCCUneu_Btn1 AAAAAA01
Und richtigerweise, werden hier die zu HM lan gateways umprogrammierten CCU2 nicht als CUL_HM erkannt?
im nächsten Versuch habe ich einen Türkontakt rüberkopiert, allein mit der Defmod Zeile, ohne jedes attr.
List zeigt:
Reserve 56CADC
VCCUneu AAAAAA
VCCUneu_Btn1 AAAAAA01
Die Übernahme wurde als executed angezeigt. Der Gerätetyp ist virtuell.
Ein modelForce bringt dann mehr Internals, so dass der Kontakt nun über die HMLGW mit der VCCUneu spricht. Der Zustand wird sofort und richtig im STATE abgebildet. Das Device bleibt aber virtuell obwohl es auch einen subType liefert. Der lautet ThreeStateSensor, wohl richtig für einen normalen LED-Türkontaktsensor.
Nun erneut das Gerät gelöscht.
erneut zeigt das List, dass das Gerät nicht da ist.
Nun die Übernahme mit allen Zeilen aus dem Raw wie folgt:
defmod Reserve CUL_HM 56CADC
attr Reserve IODev HMLGW2
attr Reserve actCycle 001:05
attr Reserve actStatus alive
attr Reserve autoReadReg 4_reqStatus
attr Reserve devStateIcon open:fts_window_2w_open@red closed:fts_window_2w@green
attr Reserve event-on-change-reading .*
attr Reserve firmware 1.0
attr Reserve group Fenster
attr Reserve icon fts_window_2w
attr Reserve room CUL_HM
attr Reserve serialNr OEQ0228104
attr Reserve subType threeStateSensor
Die Meldung nach dem Execute ist:
Executed everything, no errors found.
nach dem OK zu dieser Meldung bleibt das RAW def Fenster stehen, nach dem schließen findet man das Gerät in Raum CUL_HM. Es hat nun als Readings die Serialnummer und die firmware
Readings
Activity
unknown
2020-12-08 14:47:53
D-firmware
1.0
2020-12-08 14:45:39
D-serialNr
OEQ0228104
2020-12-08 14:45:39
recentStateType
info
2020-12-08 14:48:03
Das attr subtype ist jedoch virtual.
Es wurde kein modelforce genutzt beim Kopieren. ebenso nicht die VCCUneu mit aufgführt.
ein nachträgliches modelForce bringt dann alle attr zurück, das Setzen der IOgrp VCCUneu bringt dann auch einige readings. Es fehlt aber der sabotage-state. Zudem fehlt das pairing zur VCCUneu.
Letzter Versuch:
defmod Reserve CUL_HM 56CADC
attr Reserve IODev HMLGW2
attr Reserve IOgrp VCCUneu
attr Reserve actCycle 001:05
attr Reserve actStatus alive
attr Reserve autoReadReg 4_reqStatus
attr Reserve devStateIcon open:fts_window_2w_open@red closed:fts_window_2w@green
attr Reserve event-on-change-reading .*
attr Reserve firmware 1.0
attr Reserve group Fenster
attr Reserve icon fts_window_2w
attr Reserve room CUL_HM
attr Reserve serialNr OEQ0228104
attr Reserve subType threeStateSensor
Im Ergebnis lief es wieder fehlerlos durch wie oben geschrieben. Als Readings nur firmware und serialNr., kein pairing in den internals.
ModelForce bringt den Modelltyp und den subType three statesensor, sieht auch ok aus, pairing nicht vorhanden. Sabotgeerror auch nicht.
Noch ein Versuch wie ganz am Anfang mal:
defmod Reserve CUL_HM 56CADC
attr Reserve IODev HMLGW2
attr Reserve IOgrp VCCUneu
attr Reserve actCycle 001:05
attr Reserve actStatus alive
attr Reserve autoReadReg 4_reqStatus
attr Reserve devStateIcon open:fts_window_2w_open@red closed:fts_window_2w@green
attr Reserve event-on-change-reading .*
attr Reserve firmware 1.0
attr Reserve group Fenster
attr Reserve icon fts_window_2w
attr Reserve peerIDs 00000000,
attr Reserve room CUL_HM
attr Reserve serialNr OEQ0228104
attr Reserve subType threeStateSensor
attr Reserve model HM-SEC-SCo
Auch dies klappt nicht. Er meckert auch nicht bei model. ich kann auch nicht alle Readings auslesen, auch nicht durch setzen des expert.
Nun weiß ich nicht weiter....
Zitat von: Otto123 am 08 Dezember 2020, 15:11:22
Du hast jetzt tagelang mit deinen IOs rumgespielt, mich wundert es nicht das schon alle Geräte da sind. Aber das sieht man doch? Einfach im Raum CUL_HM schauen.
Ein Blick in den Raum CUL_HM zeigt, dass es nur die von mir angelegten Device gibt und keine, die sich selber in das neue System geschlichen haben.
Nur zur Sicherheit: AAAAAA ist deine hmId aus dem alten System?
Ansonsten verstehe ich bei den hier dokumentierten Versuchen nur Bahnhof. Ich denke der angedachte Weg ist für Dich falsch.
und wenn dann modelForce sofort und nicht irgendwann :(
attr subType darfst Du nicht mitgeben, hatte ich doch schon geschrieben :-[
Zitat von: misave am 08 Dezember 2020, 15:31:29
Ein Blick in den Raum CUL_HM zeigt, dass es nur die von mir angelegten Device gibt und keine, die sich selber in das neue System geschlichen haben.
Dann hätte es diese Meldung nie geben dürfen!
HMid DEF already used by HM_56CADC
hallo Otto,
die beiden Systeme sehen wie folgt aus:
FHEM auf 6.0 (neues System)
VCCUneu AAAAAA
HMLGW1 owner AAAAAA, owner_CCU kein Eintrag
HMLGW2 owner AAAAAA, owner_CCU kein Eintrag
keine weiteren Einträge in CUL_HM
FHEM 5.6 (altes System)
VCCU AAAAAA
HMLAN1 owner AAAAAA, owner_CCU VCCU
HMLAN2 owner AAAAAA, owner_CCU VCCU
dutzende Geräte im Raum CUL_HM, u. a. der Reservetürkontakt, den ich nun mehrmals mit verschiedenen DefMod-Befehlen rüberkopieren wollte. Die verschiedenen Versuche stehen oben in meinem Text. ich gebe zu etwas lang, aber ich habe nun zwischen dem defMod (nur die echte defmod-Zeile und KEIN einziges Attr) und einigen Varianten mit und ohne modelforce; mit und ohne VCCU-Name gemacht. attr subtype habe ich auch mal weggelassen, mal mitgemacht. Das Ergebnis ist immer dasselbe....
Ich hatte Dir ja ganz am Anfang mal meinen Vorschlag zum Rüberkopieren aufgeschrieben. Da hatte ich den modelForce drin als Frage....
Zitat von: frank am 08 Dezember 2020, 15:23:39
welchen vorteil hat eigentlich dieses stückweise rumschaufeln von kleinen portionen der fhem.cfg.
die ganzen device daten fehlen dann ja immer noch.
Hallo Frank,
ja da hast du Recht. Aber meine fhem.cfg basiert ja auf einem FHEM 5.6 was die Syntax aller Programmierungen betrifft. Ebenso sind die Geräte in der alten Welt definiert. ich hatte mir schon vorher überlegt, dass ich die config nicht mal eben einfach auf das neue system als fhem.cfg bringe. ich befürchte aber, dass ich in der Menge der Fehlermeldungen ersticke.
Zudem hat das neue System eigene IOs (zu HMLGW umprogrammierte CCU2 während das alte System mit echten HMLAN arbeitet.
ZitatIch hatte Dir ja ganz am Anfang mal meinen Vorschlag zum Rüberkopieren aufgeschrieben. Da hatte ich den modelForce drin als Frage....
und du hast meine Antwort aus #12 mal so probiert?
Aber vielleicht funktioniert das alles mittlerweile nicht mehr. Dann kopiere doch einfach über edit Files den Inhalt Deiner alten Installation in die neue und versuch das nachzuarbeiten (IP Adresse des Gateways)?
Zitat von: Otto123 am 08 Dezember 2020, 16:02:42
und du hast meine Antwort aus #12 mal so probiert?
Aber vielleicht funktioniert das alles mittlerweile nicht mehr. Dann kopiere doch einfach über edit Files den Inhalt Deiner alten Installation in die neue und versuch das nachzuarbeiten (IP Adresse des Gateways)?
Ja nr 12 von Dir habe ich gemacht. Dort steht ja auch die Ergänzung drin mit modelforce. Du könntest diesen Versuch in meinem langen Text wiederfinden.
die Gateways alt haben 192.168.2.xx0 bzw. 192.168.2.xx2
die neuen Gateways haben 192.168.2.y3 bzw. 192.168.2.y4
Alle liegen im Adressbereich der fritzbox, wobei die alten in einem Bereich liegen, die die Fritzbox bei ihrer freien Vergabe von IPs für neue Teilnehmer nicht nutzen kann.
Wie gesagt, die Meldungen des Fensterkontakts kommen in beiden Welten an. Aber das pairing nicht. Oder muss ich dazu vielleicht VOR dem defmod im neuen System das alte System ausschalten, damit der Türkontakt am Anfang nur mit der neuen VCCU redet?
Nun ja, das fhem.cfg einfach so rüberkopieren ins neue System geht nur Stückweise, denn die neue Welt hat schon virtuelle Geräte und echte HMLGW und echte Fritzbox....
Naja die Henne und das Ei :)
Der Fensterkontakt ist natürlich auch ein sehr fragiles Beispiel!
Weil: für die Readings musst Du getConfig machen. Und beim FK musst Du Knöpfchen drücken ohne ihn auszulösen um die Übertragung durchzuführen!!!
Und Fehlermeldungen aus dem alten System solltest Du im neuen nicht suchen (Es fehlt aber der sabotage-state.)
Ich probiere es nochmal in meinem Testsystem - aber jetzt gibt es erstmal Glühwein
Otto,
das der Fensterkontakt so fragil ist war mir nicht bewusst. Er liegt aber hier so rum auf dem Tisch und war nie eingebaut, nur als Reserve im alten System hinterlegt. Also habe ich mir den auf den Tisch vor die Tastatur gelegt.
ja das get config von der Zentrale aus gesendet muss ich beim Fensterkontakt mit Knöpfchen drücken (kurz) bis er leuchtet beantworten. das geht auch ganz gut ohne den Kontakt auszulösen.
Meine nächste Idee ist nun, den Fensterkontakt im alten System zu löschen. Aber das System lasse ich weiterlaufen. Den Fensterkontakt resette ich NICHT. er glaubt also weiterhin, dass du seine Meldungen zu einer Zentrale mit der HMID AAAAAA entsorgen kann. Das alte System stellt dann die Meldungen des Fensterkontaktes nicht mehr da. Obwohl autocreate in beiden Systemen aktiv ist, dürfte keines der Systeme die Meldungen darstellen.
Dann kopiere ich per defmod den Fensterkontakt in das neue System und schaue was passiert. ich verwende nur diejenigen attr beim Kopieren, die zu keiner Meldung beim Kopieren führen (außer den Success).
Und dann müsste sich vielleicht der Fensterkontakt wieder "wohl" fühlen, dass er eine Zentrale mit HMID AAAAAA gefunden hat, di ihn haben will.
Wenn das so nicht klappt könnte ich das alte System während des Kopierens ausschalten, wobei ich aber nicht glaube, dass es einen Unterschied macht. Der Fensterkontakt pollt seine Meldungen ja in den Äther und nur die gateways, deren Zentrale die 6stellige HM-Nummer (nicht Seriennummer) kennen, können die Meldungen in das System aufnehmen.
Die letzte Alternative ist dann das neu Pairing aller Geräte in die neue Welt. Wobei ich dann mit einer anderen HMID für die VCCU und deren Horchposten ins Rennen gehe. Ich kann dann aus der alten fhem.cfg bei jedem Gerät die Teile rauskopieren die ich im neuen System haben darf. Manche attr sind ja anders geworden.
Und wenn ich dann alles fertig habe, werde ich zwar wie bisher auch schön regelmäßig backups vom FHEM ziehen und extern abspeichern und auch regelmäßig eine .img der Speicherkarte machen, aber dann neu einmal pro Woche ein update in fhem machen und auch in der Linux-Welt. Dies hatte ich ganz am Anfang auch so gehandhabt aber dann doch mehr und mehr geschludert.
Hallo Otto,
ich habe auch noch zwei 1-fach Aktoren, angelernt am alten System. Wenn ich mit denen das Kopieren besser spielen kann, nehme ich die. Habe auch eine Versuchsverdrahtung mit Leuchtmittel, damit ich diese Aktoren wegen des N-Leiters auch auf dem Tisch anlernen kann bevor ich sie in die Wand einbaue.
Und ja, als Elektrofachkraft weiß ich, dass man das so mit fliegender Verdrahtung nicht macht.
Genieß den Glühwein ohne Weihnachtsmarkt.
@Otto,
witzig ist auch, dass der Fensterkontakt im alten System nun eine IOgrp in den attr hat, die es in dem alten System gar nicht gibt, nämlich VCCUneu. Und da es diese VCCU nicht gibt im alten System ist sie als attr auch nicht als Link zum entsprechenden Device.
Seit ihr euch sicher, dass man einen Umzug (wenn überhaupt noch) mit derselben HMID in allen IO-Geräten und VCCUs machen kann?
Zusätzlich reagiert die eine HMLGW1 im neuen System mit einer immer wieder kehrenden Meldung:
2020.12.08 19:33:05 3: HMLGW1: Unknown code A0D90A6414F24DCAAAAAA01CF2240::-43:HMLGW1, help me!
Darin ist AAAAAA die HMID, die -43 wohl der RSSI wert, die 4F24DC wohl die CUL_HM Nummer eines Gerätes.
Ich habe (vorbereitet vorm Glühwein) jetzt getestet:
Altes System set HMLAN1 close
Neues System set HMLAN1 open
Ich habe in beiden System die Namen gleich!
Die Raw Def vom Alten
defmod RolloAZL CUL_HM 152AF2
attr RolloAZL userattr Level Level_map structexclude
attr RolloAZL .mId 0005
attr RolloAZL IODev HMLAN1
attr RolloAZL IOgrp VCCU:ser2netUart
attr RolloAZL Level st_Rollo_N
attr RolloAZL autoReadReg 4_reqStatus
attr RolloAZL devStateIcon down.*:control_arrow_down up.*:control_arrow_up stop.zu:fts_shutter_100:auf stop.auf:fts_shutter_10:zu stop.1.*:fts_shutter_90 stop.2.*:fts_shutter_80 stop.3.*:fts_shutter_70 stop.4.*:fts_shutter_60 stop.5.*:fts_shutter_50 stop.6.*:fts_shutter_40 stop.7.*:fts_shutter_30 stop.8.*:fts_shutter_20 stop.9.*:fts_shutter_10
attr RolloAZL event-on-change-reading .*
attr RolloAZL eventMap on:auf off:zu
attr RolloAZL expert 1_allReg
attr RolloAZL firmware 1.5
attr RolloAZL model HM-LC-BL1-FM
attr RolloAZL peerIDs 00000000,152AF201,152AF202,16B1400B,16B1400C,200DB805,
attr RolloAZL room Arbeitszimmer
attr RolloAZL serialNr IEQ0016505
attr RolloAZL stateFormat motor
attr RolloAZL subType blindActuator
attr RolloAZL webCmd down:pct:up
Daraus diese gemacht und "eingeworfen"
defmod RolloAZL CUL_HM 152AF2
attr RolloAZL IODev HMLAN1
attr RolloAZL IOgrp VCCU:ser2netUart
attr RolloAZL autoReadReg 4_reqStatus
attr RolloAZL devStateIcon down.*:control_arrow_down up.*:control_arrow_up stop.zu:fts_shutter_100:auf stop.auf:fts_shutter_10:zu stop.1.*:fts_shutter_90 stop.2.*:fts_shutter_80 stop.3.*:fts_shutter_70 stop.4.*:fts_shutter_60 stop.5.*:fts_shutter_50 stop.6.*:fts_shutter_40 stop.7.*:fts_shutter_30 stop.8.*:fts_shutter_20 stop.9.*:fts_shutter_10
attr RolloAZL event-on-change-reading .*
attr RolloAZL eventMap on:auf off:zu
attr RolloAZL firmware 1.5
attr RolloAZL modelForce HM-LC-BL1-FM
attr RolloAZL peerIDs 00000000,152AF201,152AF202,16B1400B,16B1400C,200DB805,
attr RolloAZL room Arbeitszimmer
attr RolloAZL serialNr IEQ0016505
attr RolloAZL stateFormat motor
attr RolloAZL webCmd down:pct:up
Nach wenigen Sekunden sieht es so aus:
Internals:
CFGFN
DEF 152AF2
FUUID 5fcfd56c-f33f-27f7-fb90-18441e541b8bf594
HMLAN1_MSGCNT 41
HMLAN1_RAWMSG E152AF2,0000,7D9FEDBD,FF,FFDD,32A010152AF2200DB8030000
HMLAN1_RSSI -35
HMLAN1_TIME 2020-12-08 20:35:30
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 41
NAME RolloAZL
NOTIFYDEV global
NR 2208
STATE stop:auf
TYPE CUL_HM
chanNo 01
lastMsg No:32 - t:10 s:152AF2 d:200DB8 030000
peerList self01,self02,16B1400B,16B1400C,VCCU_chn-05,
protLastRcv 2020-12-08 20:35:30
protRcv 32 last_at:2020-12-08 20:35:30
protSnd 42 last_at:2020-12-08 20:35:30
protState CMDs_done
rssi_HMLAN1 cnt:1 min:-33 max:-33 avg:-33 lst:-33
rssi_at_HMLAN1 cnt:41 min:-36 max:-35 avg:-35.04 lst:-35
READINGS:
2020-12-08 20:35:15 D-firmware 1.5
2020-12-08 20:35:15 D-serialNr IEQ0016505
2020-12-08 20:35:21 PairedTo 0x200DB8
2020-12-08 20:35:21 RegL_00. 00:00 02:81 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:20 0B:0D 0C:B8
2020-12-08 20:35:22 RegL_01. 00:00 08:00 09:00 0A:00 0B:00 0C:F0 0D:01 0E:04 0F:05 10:00
2020-12-08 20:35:27 RegL_03.16B1400B 00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:93 9F:00
2020-12-08 20:35:29 RegL_03.16B1400C 00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:68 9F:00
2020-12-08 20:35:30 RegL_03.VCCU_chn-05 00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:52 0D:63 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:63 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:52 8D:63 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:63 9F:00
2020-12-08 20:35:24 RegL_03.self01 00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:88 0C:88 0D:63 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:63 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:52 8D:63 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:63 9F:00
2020-12-08 20:35:26 RegL_03.self02 00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:99 0C:99 0D:63 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:63 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:52 8D:63 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:63 9F:00
2020-12-08 20:35:20 cfgState updating
2020-12-08 20:35:30 commState CMDs_done
2020-12-08 20:35:16 deviceMsg on (to VCCU)
2020-12-08 20:35:16 level 100
2020-12-08 20:35:16 motor stop:on
2020-12-08 20:35:16 pct 100
2020-12-08 20:35:23 peerList self01,self02,16B1400B,16B1400C,VCCU_chn-05,
2020-12-08 20:35:16 recentStateType info
2020-12-08 20:35:16 state on
2020-12-08 20:35:16 timedOn off
helper:
HM_CMDNR 50
cSnd 01200DB8152AF2010416B1400C03,01200DB8152AF20104200DB80503
mId 0005
peerFriend peerSens,peerVirt
peerIDsRaw ,152AF201,152AF202,16B1400C,16B1400B,200DB805,00000000
peerOpt 3:blindActuator
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey self01,self02,16B1400B,16B1400C,VCCU_chn-05,:no:1607456115.41469
TmplTs 1607456115.41469
cmdKey 1:1:0::RolloAZL:0005:01:self01,self02,16B1400B,16B1400C,VCCU_chn-05,
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
down [(-changeValue-|{10})] [(-ontime-|{0})] [(-ramptime-|{0})]
eventL -peer- -cond-
eventS -peer- -cond-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
pair noArg
pct -value- [-ontime-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{self01})]
pressS [(-peer-|{self01})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
stop noArg
toggle noArg
toggleDir noArg
tplDel -tplDel-
unpair noArg
up [(-changeValue-|{10})] [(-ontime-|{0})] [(-ramptime-|{0})]
lst:
condition slider,0,1,255
peer 16B1400B,16B1400C,VCCU_chn-05,self01,self02
peerOpt remove_16B1400B,remove_16B1400C,remove_VCCU_chn-05,,TeamDev_Btn1,VCCU_Btn1
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
dir:
cur stop
expert:
def 0
det 0
raw 1
tpl 0
io:
newChn +152AF2,00,00,00
nextSend 1607456130.65428
rxt 0
vccu VCCU
p:
152AF2
00
00
00
prefIO:
ser2netUart
mRssi:
mNo 32
io:
HMLAN1:
-27
-27
myHmUARTLGW:
ser2netUart:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
prs 1
rpt:
IO HMLAN1
flg A
ts 1607456130.55562
ack:
HASH(0x4620db8)
328002200DB8152AF200
rssi:
HMLAN1:
avg -33
cnt 1
lst -33
max -33
min -33
at_HMLAN1:
avg -35.0487804878049
cnt 41
lst -35
max -35
min -36
shadowReg:
tmpl:
Attributes:
IODev HMLAN1
IOgrp VCCU:ser2netUart
autoReadReg 4_reqStatus
devStateIcon down.*:control_arrow_down up.*:control_arrow_up stop.zu:fts_shutter_100:auf stop.auf:fts_shutter_10:zu stop.1.*:fts_shutter_90 stop.2.*:fts_shutter_80 stop.3.*:fts_shutter_70 stop.4.*:fts_shutter_60 stop.5.*:fts_shutter_50 stop.6.*:fts_shutter_40 stop.7.*:fts_shutter_30 stop.8.*:fts_shutter_20 stop.9.*:fts_shutter_10
event-on-change-reading .*
eventMap on:auf off:zu
expert rawReg
firmware 1.5
model HM-LC-BL1-FM
modelForce HM-LC-BL1-FM
peerIDs 00000000,152AF201,152AF202,16B1400B,16B1400C,200DB805,
room Arbeitszimmer
serialNr IEQ0016505
stateFormat motor
subType blindActuator
webCmd down:pct:up
Aus meiner Sicht ist das geglückt? Ich sehe alles und kann steuern :)
Zitat von: misave am 08 Dezember 2020, 19:38:55
Darin ist AAAAAA die HMID, die -43 wohl der RSSI wert, die 4F24DC wohl die CUL_HM Nummer eines Gerätes.
Dein neues System wird natürlich alle Meldungen vom alten System einfangen. Alle hören mit!
Hallo Otto,
Ich hatte bisher im alten System keines der beiden HMLANs gestoppt. Probiere ich aus. Und das neue System hat auch immer beide HMLGWs aktiv.
Hat denn dein rüberkopiertes Ein richtiges Pairing 0xAAAAAA (bei mir) im Register gesetzt bekommen? Das ist ja bei mir nicht passiert.
Zitat von: misave am 08 Dezember 2020, 20:52:53
Ich hatte bisher im alten System keines der beiden HMLANs gestoppt. Probiere ich aus. Und das neue System hat auch 8mmer beide HMLGWs aktiv.
Ich habe nur einen HMLAN1. Den stoppe ich im alten System (weil - da habe ich noch 2 andere IOs) und aktiviere ihn im neuen System. Denn er kann nur eine Verbindung haben!
ZitatEin richtiges Pairing 0xAAAAAA (bei mir) im Register gesetzt bekommen
Du kannst mein list lesen? Fehlt da das Pairing?
Ist es anhand der Listen nicht eindeutig nachvollziehbar was ich gemacht habe?
Habe dein Paired nun doch gefunden. Dein Listing ist deutlich umfangreicher und zeilenversetzter als auf der webfront Seite des Devices.
Welches attr bzw. welcher List-Befehll hat die Ausgabe der Infos erzeugt? Ich konnte zwar ein def und raw im expert attr setzen, aber es wurden keine weiteren Readings angezeigt.
Das list macht man mit list Gerätename - da steht immer alles drin. Mehr als in der normalen Webansicht
list RolloAZL
Zitat von: Otto123 am 08 Dezember 2020, 20:57:11
Ich habe nur einen HMLAN1. Den stoppe ich im alten System (weil - da habe ich noch 2 andere IOs) und aktiviere ihn im neuen System. Denn er kann nur eine Verbindung haben!Du kannst mein list lesen? Fehlt da das Pairing?
Ist es anhand der Listen nicht eindeutig nachvollziehbar was ich gemacht habe?
Das habe ich ja noch nicht versucht mit dem physikalischen HMLAN jeweils eine logische aktive Verbindung zu haben. vielleicht liegt es daran, dass ich im alten und neuen System jeweils eigene physikalische Geräte betreibe.
Mein Plan morgen ist also, das Umziehen mit einem physikalischen HMLAN zu versuchen.
Was du beim kopieren gemacht hast ist klar, du hast einige attr angepasst, z.b. modelForced eingefügt. Das Listing am Ende habe ich bisher nie erzeugt und gesehen...
Habe es gerade bei einem Aktor so gemacht und es sieht entsprechend aus.
Danke.
Das ist "logisch gesehen, das was ich gemacht habe. eins war das erste defmod (Original) zwei war das zweite defmod (modifiziert)
Also 6 Zeilen gelöscht, eine eingefügt :)
diff eins.txt zwei.txt
2,3d1
< attr RolloAZL userattr Level Level_map structexclude
< attr RolloAZL .mId 0005
6d3
< attr RolloAZL Level st_Rollo_N
11d7
< attr RolloAZL expert 1_allReg
13c9
< attr RolloAZL model HM-LC-BL1-FM
---
> attr RolloAZL modelForce HM-LC-BL1-FM
18d13
< attr RolloAZL subType blindActuator
Aber es hat nichts mit dem HMLAN1 zu tun! Du kannst es genauso machen wie Du es jetzt hast. Du machst es Dir nur unnötig schwer damit im neuen System neue Namen zu vergeben!!!
Ja die Differenz hatte ich schon haarklein rausgefunden. Ich verstehe es ja auch nicht, warum es nicht klappt. Ich probiere es erneut und prüfe über list Reserve (Name des device in beiden Systemen) ob das pairing dann richtig angezeigt wird im neuen System mit physikalisch anderen IOs und der namentlich anderen VCCU.
Interessant fand ich meinen Eintrag des Dev im alten System bzgl. IOgrp. Da stand ja der Name der anderen VCCU, allerdings in schwarz und nicht als link. Ich hätte erwartet, dass das alte System meckern wenn das DEV plötzlich einen Eintrag bekommt, den es im alten System gar nicht gibt als VCCU.
Wie gesagt ich betreibe in jedem der beiden Systeme 2 eigene HMLANs. Ich habe denen im neuen System andere Namen als im alten System gegeben, weil ich später im neuen kompletten System die alten HMLANs ebenfalls einbinde damit ich pro Etage eines habe und ich am Namen erkennen kann ob es echte HMLAN (Ufos) sind oder die umprogrammierten CCUs zu HMLGW.
Ja ok das ist auch gut. Aber dann musst Du diesbezüglich auch die defmods ändern. Für die VCCU macht es allerdings keinen Sinn! Die kann in beiden System gleich heißen, die kennen sich nicht :)
Wobei ich das noch nicht verstehe:
ZitatInteressant fand ich meinen Eintrag des Dev im alten System bzgl. IOgrp. Da stand ja der Name der anderen VCCU, allerdings in schwarz und nicht als link.
Ja die defMod hatte ich ja auch immer passend angepasst bzgl modelforce, Name des IODev und der IOGrp.
Das wär alles in meinem langen Text erkennbar oben.
Bei mir hat das neue System immer nur ein virtuelles DEV eingerichtet.
Ich probiere morgen weiter und berichte dann.
Danke danke danke.
Morgen nehme ich dann einen der schaltaktoren und kann dann auch steuern.
Kann es denn daran liegen, dass das dev aus dem alten System weiß es wird in einer Fhem 5.6 Umgebung betrieben und fühlt Tisch nicht wohl in Fhem 6.0? Kleiner Scherz am Abend.
Zitat von: misave am 08 Dezember 2020, 21:30:44
Das wär alles in meinem langen Text erkennbar oben.
Naja das klang nicht ganz so. Ich glaube man muss das Teil am Stück anlegen. Also Versuch - Irrtum - löschen - neu versuchen.
Wenn man löschen weg lässt und "rumfummelt" wird es nichts. ;) Jeder Fehler - egal in welcher Zeile wird bestraft
Ja ich lege das neue dev nur noch in einem Schritt an. Heute Nachmittag wollte und habe ich auf diese Weise herausgefunden welche attr eine Fehlermeldung beim execute erzeugen.
Zitat von: misave am 08 Dezember 2020, 21:35:19
dass das dev aus dem alten System weiß es wird in einer Fhem 5.6 Umgebung betrieben und fühlt Tisch nicht wohl in Fhem 6.0? Kleiner Scherz am Abend.
Ja ... da musst Du schauen. Die Definitionen sind uU schon ganz anders. Deswegen ja mein komplett Beispiel. Das war z.B. so ein Problem was ich nicht auf dem Schirm hatte:
attr RolloAZL expert 1_allReg
Besser mehr rausstreichen als zu viel drin lassen! Im Zweifel richtet ein getConfig alles!
den expert mode hatte ich eh schon rausgeworfen, ob das Kopieren dann den neuen mode setzt und dies nach dem execute auch anzeigt, aber danach kommt keine success meldung.
Ich konnte es nicht so ruhen lassen.
execute mit Successfull beendet. Gerät ist da, aber PairedTo 0x000000.
Anstelle zu 0xAAAAAA
Der sabotageError ist nun auch in den Readings....
Kann sich das Paired-Argument noch von alleine ändern? Ds Reading 0xAAAAA aus dem alten System wird ja nicht sichtbar rüberkopiert, zumindest erscheint es ja nicht in RAWDef.
btw,
Otto, weißt Du was das zu bedeuten hat: Readings der VCCU im neuen System. da steht state HMLGW1:UAS,HMLGW2:UAS
im alten System stehen da nur HMLAN1 und 2 aber ohne eine Zusatz mit Doppelpunkt
Readings
CommandAccepted yes 2020-12-08 22:12:12
IOopen 0 2020-12-08 15:14:45
state HMLGW1:UAS,HMLGW2:UAS, 2020-12-08 15:14:45
trigger Short_1 2020-12-07 21:05:04
trigger_cnt 1 2020-12-07 21:05:04
PairedTo liest er selbst zurück
Poste doch komplette lists :)
Also vielleicht dein defmod und das list was nach einem getConfig und etwas Zeit zurück kommt. Sonst tappe ich im Trüben
Zitat von: misave am 08 Dezember 2020, 22:17:40
btw,
Otto, weißt Du was das zu bedeuten hat: Readings der VCCU im neuen System. da steht state HMLGW1:UAS,HMLGW2:UAS
im alten System stehen da nur HMLAN1 und 2 aber ohne eine Zusatz mit Doppelpunkt
Readings
CommandAccepted yes 2020-12-08 22:12:12
IOopen 0 2020-12-08 15:14:45
state HMLGW1:UAS,HMLGW2:UAS, 2020-12-08 15:14:45
trigger Short_1 2020-12-07 21:05:04
trigger_cnt 1 2020-12-07 21:05:04
VCCU ist falsch eingerichtet! Komplettes list?
Hier das List der VCCU:
Internals:
DEF AAAAAA
FUUID 5fcd0159-f33f-cfd9-f698-8eea2a6bcb1a8893
FVERSION 10_CUL_HM.pm:0.232520/2020-11-28
HMLGW1_MSGCNT 4768
HMLGW1_RAWMSG 05000050D1A001AAAAAA56CADC00040000000000
HMLGW1_RSSI -80
HMLGW1_TIME 2020-12-08 22:21:55
HMLGW2_MSGCNT 5140
HMLGW2_RAWMSG 05000051D1A001AAAAAA56CADC00040000000000
HMLGW2_RSSI -81
HMLGW2_TIME 2020-12-08 22:21:55
IODev HMLGW2
LASTInputDev HMLGW1
MSGCNT 9908
NAME VCCUneu
NOTIFYDEV global
NR 58
NTFY_ORDER 50-VCCUneu
STATE HMLGW1:UAS,HMLGW2:UAS,
TYPE CUL_HM
assignedIOs HMLGW1,HMLGW2
channel_01 VCCUneu_Btn1
lastMsg No:D1 - t:01 s:AAAAAA d:56CADC 00040000000000
protLastRcv 2020-12-08 22:21:55
protRcv 3214 last_at:2020-12-08 22:21:55
protRcvB 214 last_at:2020-12-08 22:19:40
rssi_at_HMLGW1 cnt:4768 min:-96 max:-64 avg:-79.48 lst:-80
rssi_at_HMLGW2 cnt:5140 min:-91 max:-38 avg:-60.66 lst:-81
READINGS:
2020-12-08 22:19:45 CommandAccepted yes
2020-12-08 15:14:45 IOopen 0
2020-12-08 15:14:45 state HMLGW1:UAS,HMLGW2:UAS,
2020-12-07 21:05:04 trigger Short_1
2020-12-07 21:05:04 trigger_cnt 1
helper:
BNO 1
BNOCNT 1
HM_CMDNR 209
PONtest 1
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey :no:1607355318.00908
TmplTs 1607355318.00908
cmdKey 0:1:1::VCCUneu:FFF0:01:
cmdLst:
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
defIgnUnknown noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerSmart -peerOpt-
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt Reserve
tplDel
rtrvLst:
cmdList [({short}|long)]
listDevice noArg
param -param-
expert:
def 0
det 0
raw 1
tpl 0
io:
nextSend 1607462516.10202
prefIO
vccu VCCUneu
ioList:
mRssi:
mNo D1
io:
HMLGW1:
-80
-80
HMLGW2:
-79
-79
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_HMLGW1:
avg -79.4832214765101
cnt 4768
lst -80
max -64
min -96
at_HMLGW2:
avg -60.6669260700389
cnt 5140
lst -81
max -38
min -91
shadowReg:
tmpl:
Attributes:
IOgrp VCCUneu
expert rawReg
icon hm_ccu
model CCU-FHEM
room CUL_HM,Geräte,system
subType virtual
webCmd virtual:update
Das List des Devices dauert noch, da immer noch pending CMD
Und mal ein List auf das HMLGW (ex CCU):
Internals:
AssignedPeerCnt 0
CFGFN
CNT 8
Clients :CUL_HM:
DEF 192.168.2.64
DEVCNT 8
DevState 99
DevType LGW
DeviceName 192.168.2.64:2000
FD 15
FUUID 5fcd66bb-f33f-cfd9-40a0-f0ea73f43044eebe
LastOpen 1607451571.14027
NAME HMLGW1
NOTIFYDEV global
NR 2532
NTFY_ORDER 50-HMLGW1
PARTIAL
RAWMSG 040200
RSSI -41
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model Revilo-HM-LGW
msgLoadCurrent 0
msgLoadHistory 0/0/0/0/0/0/0/0/0/0/0/0
msgLoadHistoryAbs 0/0/0/0/0/0/0/0/0/0/0/0/0
owner AAAAAA
Helper:
CreditTimer 758
FW 66561
Initialized 1
AckPending:
LastSendLen:
3
3
Log:
IDs:
RoundTrip:
Delay 0.00429892539978027
loadLvl:
lastHistory 1607462673.96178
MatchList:
1:CUL_HM ^A......................
Peers:
READINGS:
2020-12-08 19:19:33 D-HMIdAssigned AAAAAA
2020-12-08 19:19:33 D-HMIdOriginal 411347
2020-12-08 19:19:31 D-LANfirmware 0.0.2 (outdated)
2020-12-08 19:19:33 D-firmware 1.4.1
2020-12-08 19:19:31 D-serialNr CCU2GW0001
2020-12-08 19:19:31 D-type Revilo-HM-LGW
2020-12-08 19:19:33 cond ok
2020-12-08 20:19:36 load 0
2020-12-08 19:19:33 loadLvl low
2020-12-08 19:19:31 state opened
helper:
keepAlive:
CNT 115
DEVCNT 114
DevState 99
DevType LGW-KeepAlive
DeviceName 192.168.2.64:2001
FD 24
LastOpen 1607451571.24694
NAME HMLGW1:keepAlive
NR 22181
PARTIAL
STATE opened
TEMPORARY 1
TYPE HMUARTLGW
XmitOpen 0
Helper:
NextKeepAlive 1607462929.12185
Log:
Resolve 1
IDs:
READINGS:
2020-12-08 19:19:31 state opened
Attributes:
hmId AAAAAA
icon hm_lan
room CUL_HM,Geräte,system
bei der VCCU fehlt das wesentlichste: die IOList!
attr VCCUneu IOList HMLGW1,HMLGW2
Aber wie gesagt benenne sie doch wie im alten System VCCU, das macht es einfacher ;)
Und es muss auch ein attr IODev erscheinen! das wird normal automatisch erzeugt!
Done, die HMLGWx stehen jetzt auf HMLGWx:ok
Das beseitigt aber nicht das Problem mit pairing Eintrag im kopierten Device, oder?
danke.
ja ich nenne die VCCU jetzt um.
Eine richtige und komplette Einrichtung ermöglicht die Kommunikation der Komponenten! Am Ende also auch die Erzeugung der Readings :)
Zitat von: Otto123 am 08 Dezember 2020, 22:47:49
Eine richtige und komplette Einrichtung ermöglicht die Kommunikation der Komponenten! Am Ende also auch die Erzeugung der Readings :)
Ein sehr kluger Satz zum Ende des Abends. meine Nacht ist immer um 05:30 Uhr vorbei.
Morgen mache ich weiter. dann werden sich auch die pendingCMDs beruhigt haben und fange wieder von vorne an mit defMod.
habe mal eben einen Schaltaktor rüberkopiert, war auf ANHIEB korrekt im neuen System. nur die DefMod etwas eingekürzt.
Wie Kuchen soll ich Dir denn mal nach Leipzig schicken als Belohnung?
Hallo,
mittlerweile sind fast alle physischen Geräte umgezogen. Aktoren nehmen ihr pairing ohne weiteres Zutun direkt mit, die Sensoren brauchen allerdings ein get config mit Knöpfchen drücken. Aber immerhin ist es so einfacher als komplettes Anlernen mit namensvergabe usw.
Einige notify sind auch schon umgezogen, da sich die Perl-Syntax nicht geändert hat.
Insgesamt ist das Importieren der Geräte echt gut und ich finde sorgt bei mir dafür die Struktur zu überdenken und ich werde auf jeden Fall das alte System später wieder neu aufbauen als Testsystem. ich muss dann zwar zwei Systeme aktuell halten, aber ds geht ja. Vielleicht nutze ich das zweite System auch über FHEM2FHEM falls ich mehr als eine Platine aufsetze für andere Geräte (derzeit FS20 mit Platine).
Na das klingt ja jetzt gut :) so sollte es sein. Ich war ja zwischendurch kurz vorm aufgeben ;D
Guten Morgen,
na dein Hinweis mit IOList war ja Gold wert. Ich setze diesen Thread nun auf gelöst.
Danke und noch mal und sicherlich bis bald.
Hallo Otto,
du hattest ja von möglichen attack-Meldungen geschrieben. Die kommen jetzt massenhaft im neuen System. Grund vermute ich darin, dass das neue System eine Meldung eines Aktors empfängt, der aber nicht aus diesem System heraus zu einer Handlung aufgefordert wurde. Ich vermute mal, dass das nix macht, außer das Log-file vollschreiben. Die Meldungen verschwinden dann auch sobald das alte System abgeschaltet ist.
Diese attack-meldungen kommen aber nicht für alle Geräte, aber auch für Geräte die gar nichts machen.
Im Forum werden immer solche attack-Meldungen diskutiert, aber da waren die Gründe nie der Parallelbetrieb von zwei Installationen.
Moin Michael,
ja das kann ich genau so bestätigen.
Wenn es (am Ende) stört gibt es auch den set ... clear attack
Gruß Otto
Ich habe vorallem attack Meldungen von Kanälen aus einem Funkempfänger. HM-LC-Sw1-PCB.
Der Funkempfänger hat einen Kanal, den nutze ich um einem Rauchmelder auf seinem 5V-Kontakt die am Funkempfänger anliegenden 5V von dessen Netzteil einzuspeisen und so mit einen Alarm eines "fiktiven" anderen Rauchmelders suggeriere, damit dieser Rauchmelder auch ohne Rauch lospiept.
Anmerkung: Mit diesem künstlichen Vorgaukeln eines Alarms eines anderen "per Draht verbundenen Rauchmelders" habe ich eine Alarmanlage aufgebaut. Sobald ein notify das Öffnen einer Tür oder Fenster oder eine Bewegung im Wohnzimmer feststellt, piepen 4 Rauchmelder sowie zwei Sirenen los, zudem fährt die Rolllade an der Terrasse runter und mit 15 sek Verzögerung geht oben im Flur ein Licht an. Vielleicht kann ich damit einen Einbrecher zumindest erschrecken und da er nicht weiß was danach passiert, haut er vielleicht sofort wieder ab.
In der alten Welt wurde der Empfänger jedoch mit 3 anstelle 1 Kanal durch autocreate angelegt. Das ist der alten fhem 5.6 geschulddet so weit ich das gelesen habe. Deshalb hat er witziger weise zwei weitere Kanäle 678A0B03 und ..04. Nun habe ich den beiden unnötigen Kanälen im alten System ein event-on-update-reading none (oder müsste hier .*:none stehen?) mitgegeben. Hilft aber nicht, um Log-Einträge im neuen System zu verhindern.
im neuen System existieren die Kanäle nicht, ich musste eh nach dem Importieren des Funkempfänger den Kanal 1 aus dem alten System separat rüberkopieren. Diesen Kanal hat das Importieren des Geräts nicht mitgenommen.
Leider kann ich im neuen System die Kanäle 2 und 3 gar nicht blockieren oder so, da es die real nicht gibt.
attack gibt es immer dann, wenn fhem feststellt, dass ein device von einem "unbekannten" angefunkt wird.
edit:
mit HMinfoTools.js kannst du das sehr schön "live" verfolgen.
https://forum.fhem.de/index.php/topic,112825.0.html (https://forum.fhem.de/index.php/topic,112825.0.html)
Ja das hatte Otto mir ja schon angedroht, dass das passieren wird. Aber es passiert nur bei wenigen Geräten, die mittlerweile in beiden System parallel bekannt sind.
Zudem habe ich drei solcher Funkempfänger installiert, aber nur zwei von denen zeigen im neuen System diese attack, der dritte meckert nicht.
Und ja ich weiß, dass dieser 1-Kanal-Funkempfänger gar keine vier Kanäle hat. Ich will ja nur die attack Meldungen im neuen System unterdrücken....
ZitatUnd ja ich weiß, dass dieser 1-Kanal-Funkempfänger gar keine vier Kanäle hat. Ich will ja nur die attack Meldungen im neuen System unterdrücken....
unterdrücken geht nicht, wenn devices in 2 systemen definiert sind.
das "fremdsystem" darf halt nicht die devices ansprechen.
ich hatte gerade noch einen link im vorherigen beitrag eingefügt.
HMInfo habe ich eh installiert. Damit suche ich gerade unvollständige peers raus und versuche die zunächst alle zu löschen.
Das steht auch was drin von errors, aber das sind nicht so viele....im Logfile stehenden dutzende hintereinander von immer den selben zwei Funkempfängern und ab und einem Bewegungsmelder.
Wo sollte ich diese atck Meldungen beim HMInfo denn abgreifen können?
zeig mal ein list von hminfo.
sorry.
du musst erst "set hminfo update" machen.
danach das "list hminfo".