deassociate bringt error "Invalid command/argument 81190009"

wg25 · 12 September 2020, 06:09:38

Moin zusammen,

beim "lösen" der Verbindung (associate) zwischen HT und FK bekomme ich im HT Device immer die error Nachricht als Reading "Invalid command/argument 81190009". Ich wähle den zu entfernenden peer aus der DropDown Liste aus. Der FK bleibt somit weiterhin in der peer Liste des HT stehen und ob er nun wirklich raus ist oder nicht, keine Ahnung...

Hat jemand dieses Problem auch beobachtet?

Danke und Gruß
Arne

Wzut · 14 September 2020, 07:09:50

Da brauch ein paar Infos mehr , am besten die beiden Partner und das CM Device auf verbose 5 stellen, den Befehl ausführen und dann den entsprechenden Log Abschnitt hier posten. Geht es nur in eine Richtung schief oder lässt sich die Gegenseite lösen ?

wg25 · 15 September 2020, 15:15:14

Habe jetzt ein wenig rumgespielt. HT, FK und cm device auf verbose 5 gesetzt. Dabei ist mir aufgefallen, dass alle associates und deassociates in der sendqueue "hängen" bleiben. Und das bei unterschiedlichen FK und HT Kombinationen. Immer verbunden mit "Fenster auf, ein wenig gewartet", "Fenster zu, ein wenig gewartet" und das mehrfach. Die Queue wird nicht geleert bzw. versendet. Trotzdem reagiert der HT auf ein geöffnetes Fenster (Symbol im Display erscheint). Der Auszug aus dem Log (hier associate) wiederholt sich ständig. Was auffällt ist der angeblich vorhandene zweite CUL. Habe ich nicht...

Code Auswählen

2020.09.15 14:51:34 5: cm, Send Queue 2 packets in queue
2020.09.15 14:51:34 4: cm, Send Queue packet for ShutterContact MAX_Wohnzimmertuer_FK exists
2020.09.15 14:51:34 5: cm, IODev CULMAX, len 11, msgcnt BA, msgflag 00, msgType Ack, src 123456, dst 1a64db, group 0, payload 00, rssi -74
2020.09.15 14:51:34 4: cm, packet from ourselves or a other CUL [123456 / 0], - ignoring !
2020.09.15 14:51:34 5: cm, IODev CULMAX, len 11, msgcnt BA, msgflag 06, msgType ShutterContactState, src 1a64db, dst 123456, group 0, payload 12, rssi -50
2020.09.15 14:51:34 5: cm: dispatch MAX,1,ShutterContactState,1a64db,12
2020.09.15 14:51:34 5: MAX_Parse, MAX,1,ShutterContactState,1a64db,12
2020.09.15 14:51:34 5: MAX_Wohnzimmertuer_FK, bat 0, rferror 0, isopen 1, unkbits 0
2020.09.15 14:51:37 5: cm, Send Queue 2 packets in queue
2020.09.15 14:51:37 4: cm, Send Queue packet for ShutterContact MAX_Wohnzimmertuer_FK exists
2020.09.15 14:51:40 5: cm, Send Queue 2 packets in queue
2020.09.15 14:51:40 4: cm, Send Queue packet for ShutterContact MAX_Wohnzimmertuer_FK exists
2020.09.15 14:51:43 5: cm, Send Queue 2 packets in queue
2020.09.15 14:51:43 4: cm, Send Queue packet for ShutterContact MAX_Wohnzimmertuer_FK exists
2020.09.15 14:51:43 5: cm, IODev CULMAX, len 11, msgcnt BB, msgflag 00, msgType Ack, src 123456, dst 1a64db, group 0, payload 00, rssi -74
2020.09.15 14:51:43 4: cm, packet from ourselves or a other CUL [123456 / 0], - ignoring !
2020.09.15 14:51:43 5: cm, IODev CULMAX, len 11, msgcnt BB, msgflag 06, msgType ShutterContactState, src 1a64db, dst 123456, group 0, payload 10, rssi -59.5
2020.09.15 14:51:43 5: cm: dispatch MAX,1,ShutterContactState,1a64db,10
2020.09.15 14:51:43 5: MAX_Parse, MAX,1,ShutterContactState,1a64db,10
2020.09.15 14:51:43 5: MAX_Wohnzimmertuer_FK, bat 0, rferror 0, isopen 0, unkbits 0
2020.09.15 14:51:46 5: cm, Send Queue 2 packets in queue
2020.09.15 14:51:46 4: cm, Send Queue packet for ShutterContact MAX_Wohnzimmertuer_FK exists

Wzut · 15 September 2020, 17:30:36

ok,
a. nur mit Fenster auf/zu weckst du den FK nicht ! Das ist so ein Mythos der sich hartnäckig hält aber halt nicht der Wahrheit entspricht.
Aufwecken zum pairing bzw unpairing geht nur mit dem config Knopf ! Erst dann werden die wartenden Telegramme in der Sendqueue abgerabeitet, sieht man dann auch wieder im Log. Dein HT reagiert auf den nicht gepeerten FK weil dieser Brodcast Nachrichten verschickt, auch das kannst du du in den Readings des FK sehen wenn du das Attribut debug setzt. ( Reading sendTo_ )

b. ich sehe da keinen zweiten CUL lediglich

Code Auswählen

packet from ourselves or a other CUL [123456 / 0], - ignoring !
wobei bei dir vermutlich ourselves zutrifft falls dein cm Device mit der MAX Id 123456 läuft.

wg25 · 19 September 2020, 06:47:20

Danke, das war es.

gvzdus · 25 Oktober 2020, 06:47:16

Ich hänge mich mal an diesen Thread, weil er mein erster und halbwegs zielführender Google-Treffer war. Meine Situation:

CUL auf Adresse 123456
WT ist noch mit einem der durch Baustaub zerstörten MAXe gepairt - das kostet mutmaßlich Batterie

Ich erhalte für das Wandthermostat (eg_wohnz_wt1) ein

Code Auswählen

2020-10-25_06:35:30 eg_wohnz_wt1 peerList: Broadcast,MAX_150e15,eg_wohnz_t1,eg_wohnz_t2,eg_wohnz_t3
2020-10-25_06:35:30 eg_wohnz_wt1 peerIDs: 000000,150e15,15f8ad,16015e,160171

Daraufhin habe ich mir zunächst wieder den MAX_150e15 definiert - das Gerät hatte ich wahrscheinlich schon gelöscht.
Wenn ich jetzt

Code Auswählen

set eg_wohnz_wt1 deassociate MAX_150e15
aufrufe, erhalte ich im Logfile auf verbose 5:

Code Auswählen


2020-10-25_08:10:00 eg_wohnz_wt1 lastcmd: set_deassociate MAX_150e15
2020-10-25_08:10:03 eg_wohnz_wt1 error: Invalid command/argument  8119012A

und für die CUL:

Code Auswählen


2020.10.25 08:10:00 4: eg_wohnz_wt1, Setting deassociate, Destination 150e15, destType 1 [HeatingThermostat]
2020.10.25 08:10:01 4: cm, send -> cmd:RemoveLinkPartner, msgcnt:52, flags:00, Cmd2id:21, src:MAX_123456 , dst:eg_wohnz_wt1 , gid:00 , payload:150e1501 , cul:none
2020.10.25 08:10:01 5: cm, send packet: 0e520021123456156f9900150e1501
2020.10.25 08:10:01 5: cm, Send Queue 1 packet in queue
2020.10.25 08:10:01 5: cm, Send Queue CUL_0 -> needPreamble: 1, necessaryCredit: 112, credit10ms: 900, CUL_0 CMD_LAST_H: 10
2020.10.25 08:10:01 4: cm, Send Queue packet send : Zs0e520021123456156f9900150e1501 to eg_wohnz_wt1 with CUL_0
2020.10.25 08:10:02 5: cm, Send Queue 1 packet in queue
2020.10.25 08:10:03 5: cm, IODev CUL_0, len 14, msgcnt 52, msgflag 02, msgType Ack, src 156f99, dst 123456, group 0, payload 8119012A, rssi -73.5
2020.10.25 08:10:03 4: cm, NACK from eg_wohnz_wt1 for cmd RemoveLinkPartner !
2020.10.25 08:10:03 5: cm: dispatch MAX,1,Ack,156f99,8119012A
2020.10.25 08:10:03 5: MAX_Parse, MAX,1,Ack,156f99,8119012A
2020.10.25 08:10:03 1: MAX_Parse, device eg_wohnz_wt1 answered with: Invalid command/argument 8119012A
2020.10.25 08:10:03 5: cm, Send Queue 1 packet in queue
2020.10.25 08:10:03 4: cm, Send Queue NACK from eg_wohnz_wt1 for RemoveLinkPartner, removing from queue
2020.10.25 08:10:03 5: cm, Send Queue is now empty

Ich weiß, dass es ggf. Mecker gibt, aber meine CUL läuft auf:

Code Auswählen

V 1.66_nocredits CUL868

Ich hoffe, dass das irrelevant ist.

Wzut · 25 Oktober 2020, 08:08:15

Leider endet dein Log Abschnitt bevor das deassoc ausgeführt wird und das NACK vom WT kommt.

gvzdus · 25 Oktober 2020, 08:14:33

Sorry! Ich habe - um den Thread nicht vollzumüllen - die (hoffentlich) vollständige Antwort eines erneuten Versuchs in meinen obigen Beitrag reineditiert.

Wzut · 25 Oktober 2020, 08:33:50

OK, da kommt ein NACK vom WT zurück. Es gibt noch eine ähnliche Meldung hier im Forum zum Thema deasso fakeShutterContact.
Da frage ich mich jetzt, hat das überhaupt jemals richtig funktioniert oder habe ich da was verschlimmbessert.
Bleibt wohl nur ein Test mit einem orginal Cube um zu sehen was der in so einem Fall dem Gerät schickt und wie dessen Antwort dann ausschaut.

Für dich bleibt dann bis dahin nur die Möglichkeit das WT einem Werksreset zu unterziehen (drei Finger Griff oder set factoryReset) und danach neu pairen und alle Parameter neu setzen. Sollte mit saveConfig und restore schnell gehen. Die beiden Readings peerList & peerId dann löschen und sich neu aufbauen lassen.

vklaffehn · 26 November 2020, 09:04:36

Moin!
Ich hänge mich mal hier dran, wenn es erlaubt ist.

Ich habe dasselbe Problem, Ich habe einen WT und einen HT, die mal zusammengearbeitet haben. Nun soll der HT standalone arbeiten, also habe ich versucht, die Geräte per 'deassociate' zu trennen.
Die erste Frage : Das muss man doch beidseitig machen, oder? Alles andere scheint mir sonst unlogisch.....
Vom WT kommt auch ein ACK, vom HT ein NACK, im WT steht aber danach das WT noch in der peerList, außerdem hat das WT einen rferror. Verbose 5 auf meinem CUL_MAX zeigt mir auch an dass die Adresse des HT weiterhin in den Sendepaketen des WT drinsteht, der antwortet aber trotz des NACK nicht mehr.

Das 'Poblem' ist, dass da ein Zimmer komplett läuft mit WT, HT und zwei FK, der extra HT (im Zimmer davor) sollte nur vorübergehend mit dem WT gesteuert werden, da da ein Heizungsventil defekt war und die Heizung im Raum nur warm wurde, wenn die Heizung davor auch aufgedreht war. Außerdem ist das Zimmer vermietet und ich möchte da nicht so drin rumbasteln müssen, wenn es auch per FHEM geht. Ich hab jetzt einen factory reset des überzähligen HT gemacht, aber eigentlich habe ich keine Lust, das ganze Zimmer neu anzulernen, wenn es einen anderen Weg gibt

Irgendwie muss das doch gehen? Vielleicht setzte ich mal ein zweites FHEM mit NanoCUL auf, wo ich die alten MAX-Module reindengele? Gibt es die noch irgendwo?
MfG
Volker

Wzut · 26 November 2020, 11:08:55

Sicher das Peering muss auf beiden Seiten gelöst werden. Das ganze Thema Peering /Unpeering gefällt mir in den Modulen noch nicht, insbesondere das Geschüttel bei den FKs.
Wenn ich ab 10 Dezember dann endlich Renter bin kann ich mir das Thema nochmal in Ruhe vornehmen, d.h. alles via ELV Software und original CUBE FW machen und mitschneiden.
Bis dahin bleibt dann wohl nur der Weg via Werksreset, wobei das mittels saveConfig und restoreDevice schnell erledigt ist.

vklaffehn · 26 November 2020, 16:25:01

Danke für die Bestätigung!
Und von meiner Seite keinen Stress, es funktioniert ja so, wie es soll.
Eine Frage hätte ich da noch : Wenn ich jetzt beim WT saveconfig - factory reset - restoredevice mache, stimmen dann auch die pairings mit dem anderen HT und den FKs wieder? Oder muss ich die neu verknüpfen? Ich werde da aus dem hier diesbezüglich nicht so ganz schlau :

https://forum.fhem.de/index.php?topic=106258.0

was genau macht restoreDevice? stellt das ein in FHEM gelöschtes Device mit den vorher per saveconfig gesicherten Daten wieder her? Oder überträgt es eine vorhandene Konfigruation an das Device, also sowas wie BoostDuration,Weekplan etc.? Sind da dann auch die device pairings dabei? Oder beides?

Danke auf alle Fälle, dass Du da weiterentwickelst, mein ganzes Haus ist hier verMAXd

Wzut · 26 November 2020, 17:58:38

mach einfach mal ein set <name> saveConfig und schau dir die Ausgabe dann mit Hilfe von get <name> show_savedConfig <name> an
alles was mit setreading beginnt wird bei restoreReadings ausgeführt, also lediglich in FHEM
Die Zeilen die mit set xxx beginnen werden so auch an das Device übertragen bei restoreDevice.
In all diesen Zeilen wirst du kein set <name> associate finden, d.h. die werden nicht ausgeführt.

vklaffehn · 26 November 2020, 20:24:37

Das probiere ich am WE mal

Schade, ich hatte ja wider besseren Wissens gehofft, dass ich das hinkriege, ohne an die Hardware zu müssen.....

masterpete23 · 03 Dezember 2020, 15:30:55

Hi,

ich habe das gleiche Problem.
2 HT gepairt. Diese wollte ich nun "aufbrechen". DAbei ist mein FHEM abgestürzt:

Code Auswählen

Can't use string ("Heizung_WZ") as a HASH ref while "strict refs" in use at fhem.pl line 4992.
Nun ist eins beim anderen draußen.
Aber nicht beide. Was kann ich tun. Was sollte ich wo tun.
Ich steige nicht mehr durch und es lief halt seit der Einrichtung vor Jahren problemlos so dass ich nun alles vergessen habe