MAX zickt nach Serverumzug

Sequenzial · 07 Dezember 2017, 23:19:12

Moin,

ich habe meine Installation von meinem Low-Power-PC auf einen VMWare Server abgeschlossen.
- DB Logs übernommen (mySQL)
- Z-Wave läuft.
- JeeLink läuft.
- SignalDuinos laufen.
- Xiaomi Kram funktioniert
- HomeMatic (CUL_HM) läuft komplett
- FS20 läuft (CUL SlowRF)

Nur MAX (CUL_MAX) zickt.
Grundsätzlich funktioniert MAX, aber nicht ganz:

- Türkontakte melden ihre Veränderung an den Server (status = closed order open),
aber nach ca 8-10 Sek. ändert sich der Status in "closed (rf error)" oder "open (rf error).

rf Fehler ... wird wohl ein Empfangsproblem sein... geprüft ... CUL getauscht ... Antenne getauscht ... nö.
RSSI von -53 ist meiner Ansicht auch kein Problem. Über -70 könnte ich nachvollziehen, aber so.

Hier mal das Listing von einem Fenster Kontakt:

Code Auswählen


Internals:
   CUL_MAX_MSGCNT 3
   CUL_MAX_TIME 2017-12-07 22:58:58
   DEF        ShutterContact 18123a
   IODev      CUL_MAX
   LASTInputDev CUL_MAX
   MSGCNT     3
   NAME       Kontakt.BadWC.EG
   NR         239
   RSSI       -53
   STATE      opened (rf error)
   TYPE       MAX
   addr       18123a
   rferror    1
   type       ShutterContact
   Helper:
     DBLOG:
       RSSI:
         DBLog_Kontakt.BadWC.EG:
           TIME       1512683938.82039
           VALUE      -53
       battery:
         DBLog_Kontakt.BadWC.EG:
           TIME       1512683938.82039
           VALUE      ok
       onoff:
         DBLog_Kontakt.BadWC.EG:
           TIME       1512683938.82039
           VALUE      1
       state:
         DBLog_Kontakt.BadWC.EG:
           TIME       1512683938.82039
           VALUE      opened
   READINGS:
     2017-12-07 22:58:58   RSSI            -53
     2017-12-07 22:58:58   battery         ok
     2017-12-07 10:44:53   msgcnt          1
     2017-12-07 22:58:58   onoff           1
     2017-12-07 22:58:58   state           opened (rf error)
   internals:
     interfaces switch_active;battery
Attributes:
   IODev      CUL_MAX
   devStateIcon .*closed:fts_window_1w@green .*opened:fts_window_1w_open@red
   fp_Erdgeschoss 260,912,0,Kontakt.BadWC.EG,
   group      Fenster und Türen
   icon       fts_window_1w
   room       BadWC.EG,Fenster+Türen,•26-CUL.868 MAX!
   stateFormat state

der MAX-NanoCUL:

Code Auswählen

Internals:
   CMDS       BCFiAZEkGMKUYRTVWXefltx
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/serial/by-path/pci-0000:0b:00.0-usb-0:1.2.4.1.4:1.0-port0@38400 1201 AAB1C1
   DeviceName /dev/serial/by-path/pci-0000:0b:00.0-usb-0:1.2.4.1.4:1.0-port0@38400
   FD         9
   FHTID      1201
   NAME       cul.868.max
   NR         35
   PARTIAL    
   RAWMSG     Z0BE2063018137912345600100F
   RSSI       -66.5
   STATE      10px-kreis-gruen
   TYPE       CUL
   VERSION    V 1.66 nanoCUL433
   cul.868.max_MSGCNT 87
   cul.868.max_TIME 2017-12-07 23:02:56
   initString X21
Zr
Zaa1b2c3
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-12-07 22:43:00   cmds             B C F i A Z E k G M K U Y R T V W X e f l t x
     2017-12-07 22:30:20   credit10ms      170
     2017-12-07 23:02:56   state           Initialized
     2017-12-07 22:43:09   uptime          0 00:00:10
     2017-12-05 20:27:52   version         V 1.66 nanoCUL868
Attributes:
   comment    Plugged into 10-Port Switch at Port 4
   eventMap   Initialized:10px-kreis-gruen
   fp_Systemkomponenten 303,875,0
   group      Controller/Bridge
   hmId       AAB1C1
   icon       cul_max
   model      nanoCUL
   rfmode     MAX
   room       STATUS,•00-Server,•26-CUL.868 MAX!
   stateFormat state

und der CUL_MAX ...

Code Auswählen

Internals:
   DEF        A1B2C3
   IODev      cul.868.max
   LASTInputDev cul.868.max
   MSGCNT     89
   NAME       CUL_MAX
   NR         67
   STATE      10px-kreis-gruen
   TYPE       CUL_MAX
   addr       a1b2c3
   cnt        0
   cul.868.max_MSGCNT 89
   cul.868.max_RAWMSG Z0C70044217F0CA1416160022AC
   cul.868.max_RSSI -51
   cul.868.max_TIME 2017-12-07 23:05:29
   pairmode   0
   retryCount 0
   Helper:
     DBLOG:
       packetsLost:
         DBLog_CUL_MAX:
           TIME       1512682223.50863
           VALUE      327
   READINGS:
     2017-12-07 22:30:23   packetsLost     327
   sendQueue:
Attributes:
   IODev      cul.868.max
   event-on-change-reading .*
   eventMap   Initialized:10px-kreis-gruen
   group      Controller/Bridge
   icon       cul_max
   room       •00-Server,•26-CUL.868 MAX!
   stateFormat Initialized

Sieht für mich erst mal alles okay aus.

Achso noch der Auszug aus dem LOG (hier ein Kontakt mit den schlechtesten RSSI Werten):
Sieht bei den anderen mit besseren RSSI Werten genauso aus ...

Code Auswählen

2017-12-07 23:07:39 MAX Kontakt.BueroEG.links battery: ok
2017-12-07 23:07:39 MAX Kontakt.BueroEG.links onoff: 1
2017-12-07 23:07:39 MAX Kontakt.BueroEG.links opened
2017-12-07 23:07:39 MAX Kontakt.BueroEG.links RSSI: -76.5
2017-12-07 23:07:48 MAX Kontakt.BueroEG.links battery: ok
2017-12-07 23:07:48 MAX Kontakt.BueroEG.links onoff: 1
2017-12-07 23:07:48 MAX Kontakt.BueroEG.links opened (rf error)
2017-12-07 23:07:48 MAX Kontakt.BueroEG.links RSSI: -78

Und nun was ganz blöd ist: Taster (ECO).

Die hab ich im Haus verteilt, wie Sand am Meer und steuere damit (via notify) die HM Schalter.
Hat jetzt 3 Jahre wunderbar geklappt.

Seit dem Update:
Ich drücke auf den Max Taster: -> ok Licht schaltet (toggle) an oder aus.
Aber nach 8 Sekunden *zack* schaltet wieder.
Ich nehme an das der Notify den 2. Eintrag des MAX (mit rf error) als erneute Schaltung interpretiert und deswegen noch mal toggelt.

CUL MAX gelöscht und neu gebaut: keine Änderung
nanoCUL gelöscht und neu gebaut: keine Änderung
Kontakte gelöscht und neu angelernt: keine Änderung

*heul*

Hat jemand eine Idee?
Hab ich irgendwas übersehen? Betriebs blind?

Danke!

Gruß
Hajo

Sequenzial · 10 Dezember 2017, 13:32:20

Kurzes Update:

Ich hab ein Loch zum Keller gebohrt und mir die Max! Antenne nach oben geholt.
Ergebnis: noch bessere RSSI Werte (wie erwartet), keine Änderung in Fhem. Immer noch rf Fehler.

Übergangsweise hab ich jetzt die Notifier deaktiviert, weil mich meine Frau sonst umbringt.
Dafür kleine Nottaster an die Schalter gebaut, die die HM-Komponenten direkt schalten...

Hat echt keiner eine Idee?

Gruß
Hajo

MadMax-FHEM · 10 Dezember 2017, 13:41:59

Nur ein kurzer Thread mit "Factory Reset" als Lösung am Ende aber vielleicht ist es ja genau das.

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

EDIT: bzw. war das auch hier die "Lösung" wenn ich das richtig überflogen habe http://www.jbmedia.de/forum/viewtopic.php?f=27&t=94&start=10

Habe selbst kein MAX!

Ansonsten evtl. versuchen (zusätzlich / für die Zukunft) das Notify eingrenzender zu machen, wie sieht /sehen deine Notify aktuell aus?

Oder im Notify (vor dem Schalten) abfragen ob tatsächlich "nur" on/off (oder was der Schalter/Taster) halt schickt kommt OHNE rf error...

Gruß, Joachim

Sequenzial · 10 Dezember 2017, 19:34:02

Hi MadMax-FHEM,
danke für die Antwort.

ZitatAnsonsten evtl. versuchen (zusätzlich / für die Zukunft) das Notify eingrenzender zu machen, wie sieht /sehen deine Notify aktuell aus?

Meine Notify sind recht simpel:
(2 notify)

Code Auswählen

Taster.Esszimmer1:AN set Esszimmer.Licht toggle
Taster.Esszimmer1:AUS set Wohnzimmer.Licht toggle

So kann ich mit den 2 Tastern (Auto/Eco) am Taster.Esszimmer 2 verschiedene Lampen ansteuern

Ich hab auch die Factory defaults an den Kontakten gesetzt und nur mit FHEM neu angelernt.
Ändert aber nichts.

Ich werde wohl oder übel noch mal einen Pi zum Fhem/Max! Server machen und unter einer ganz neuen ID starten.
Wenn das klappt (ohne rf error) muss ich wohl mal den gesamten Max! Part auf dem Server löschen und unter einer neuen ID neu aufbauen ...

Ich hab ca. 30 Max! Geräte, die alle auf meinen CUL_MAX zeigen...

Code Auswählen

 
IODev CUL_MAX 
LAST InputDev CUL_MAX

Müsste im CUL_MAX nicht eigendlich stehen mit wem er alles gepairt ist?

Gruß
Hajo

MadMax-FHEM · 10 Dezember 2017, 19:53:36

Hi Hajo,

hmmm, weiß nicht wo man sieht welches MAX! wo/wie mit wem etc. verbunden ist.

Habe ja kein MAX! (mehr und eigentlich auch nur ganz kurz).

Aber es gibt aktuell einen Thread wo genau danach gefragt wird, also Assoziationen bei MAX!
Leider finde ich ihn grad nicht mehr...

Wenn es (aktuell) nur die beiden Schalter betrifft, dann evtl. halt die Abfrage ob es eine tatsächliche Änderung war oder eine "Wiederholung" mit "rf error"...

Code Auswählen

Taster.Esszimmer1:AN {if($EVENT eq "AN") {fhem("set Esszimmer.Licht toggle")}}

oder so ähnlich bzw. weiß ich ja nicht was als EVENT kommt ansonsten evtl. $EVTPART0, $EVTPART1, etc.

Dann sollten die "Doppelmeldungen" mit "rf error" zumindest nicht schalten...

Gruß, Joachim

Sequenzial · 10 Dezember 2017, 20:49:08

Hi,

hat leider den selben Effekt:

Ich hab den Notify angepasst und wieder aktiviert:

Code Auswählen


2017.12.10 20:27:29 4 : notify.Esszimmer1.A.toggle exec {if($EVENT eq "AN") {fhem("set Esszimmer.Licht toggle")}}
2017-12-10 20:27:29 CUL_HM Esszimmer.Licht set_toggle
2017-12-10 20:27:29 MAX Taster.Esszimmer1 battery: ok
2017-12-10 20:27:29 MAX Taster.Esszimmer1 onoff: 1
2017-12-10 20:27:29 MAX Taster.Esszimmer1 connection: 1
2017-12-10 20:27:29 MAX Taster.Esszimmer1 AN
2017-12-10 20:27:29 MAX Taster.Esszimmer1 RSSI: -87.5
2017-12-10 20:27:29 CUL_HM Esszimmer.Licht deviceMsg: off (to CUL_HM)
2017-12-10 20:27:29 CUL_HM Esszimmer.Licht level: 0
2017-12-10 20:27:29 CUL_HM Esszimmer.Licht pct: 0
2017-12-10 20:27:29 CUL_HM Esszimmer.Licht off
2017-12-10 20:27:29 CUL_HM Esszimmer.Licht timedOn: off
2017.12.10 20:27:32 4 : CUL_Parse: cul.868.max Z0C090250050B6F123456005001D7 -94.5
2017.12.10 20:27:32 4 : notify.Esszimmer1.A.toggle exec {if($EVENT eq "AN") {fhem("set Esszimmer.Licht toggle")}}
2017-12-10 20:27:32 CUL_HM Esszimmer.Licht set_toggle
2017-12-10 20:27:32 MAX Taster.Esszimmer1 battery: ok
2017-12-10 20:27:32 MAX Taster.Esszimmer1 onoff: 1
2017-12-10 20:27:32 MAX Taster.Esszimmer1 connection: 1
2017-12-10 20:27:32 MAX Taster.Esszimmer1 AN
2017-12-10 20:27:32 MAX Taster.Esszimmer1 RSSI: -94.5
2017-12-10 20:27:32 CUL_HM Esszimmer.Licht deviceMsg: on (to CUL_HM)
2017-12-10 20:27:32 CUL_HM Esszimmer.Licht level: 100
2017-12-10 20:27:32 CUL_HM Esszimmer.Licht pct: 100
2017-12-10 20:27:32 CUL_HM Esszimmer.Licht on
2017-12-10 20:27:32 CUL_HM Esszimmer.Licht timedOn: off
2017.12.10 20:27:40 4 : CUL_Parse: cul.868.max Z0C090250050B6F123456005001C9 -101.5
2017.12.10 20:27:40 4 : notify.Esszimmer1.A.toggle exec {if($EVENT eq "AN") {fhem("set Esszimmer.Licht toggle")}}
2017-12-10 20:27:40 CUL_HM Esszimmer.Licht set_toggle
2017-12-10 20:27:40 MAX Taster.Esszimmer1 battery: ok
2017-12-10 20:27:40 MAX Taster.Esszimmer1 onoff: 1
2017-12-10 20:27:40 MAX Taster.Esszimmer1 connection: 1
2017-12-10 20:27:40 MAX Taster.Esszimmer1 AN
2017-12-10 20:27:40 MAX Taster.Esszimmer1 RSSI: -101.5
2017-12-10 20:27:40 CUL_HM Esszimmer.Licht deviceMsg: off (to CUL_HM)
2017-12-10 20:27:40 CUL_HM Esszimmer.Licht level: 0
2017-12-10 20:27:40 CUL_HM Esszimmer.Licht pct: 0
2017-12-10 20:27:40 CUL_HM Esszimmer.Licht off
2017-12-10 20:27:40 CUL_HM Esszimmer.Licht timedOn: off
2017.12.10 20:27:53 4 : CUL_Parse: cul.868.max Z0C090250050B6F123456005001D1 -97.5
2017.12.10 20:27:53 4 : notify.Esszimmer1.A.toggle exec {if($EVENT eq "AN") {fhem("set Esszimmer.Licht toggle")}}
2017-12-10 20:27:53 CUL_HM Esszimmer.Licht set_toggle
2017-12-10 20:27:53 MAX Taster.Esszimmer1 battery: ok
2017-12-10 20:27:53 MAX Taster.Esszimmer1 onoff: 1
2017-12-10 20:27:53 MAX Taster.Esszimmer1 connection: 1
2017-12-10 20:27:53 MAX Taster.Esszimmer1 AN
2017-12-10 20:27:53 MAX Taster.Esszimmer1 RSSI: -97.5
2017-12-10 20:27:53 CUL_HM Esszimmer.Licht deviceMsg: on (to CUL_HM)
2017-12-10 20:27:53 CUL_HM Esszimmer.Licht level: 100
2017-12-10 20:27:53 CUL_HM Esszimmer.Licht pct: 100
2017-12-10 20:27:53 CUL_HM Esszimmer.Licht on
2017-12-10 20:27:53 CUL_HM Esszimmer.Licht timedOn: off

Die Notifys sind hier wohl nicht das Problem (bzw. ich kann damit das Problem nicht umgehen).
Der Taster sendet das Signal wohl 3x, was immer von FHEM akzeptiert wird.
Irgendwie scheint FHEM wirklich kein Ack zu senden (zumindest nicht an alle Geräte).
Ich hab jetzt 2 MAX Geräte gefunden die einwandfrei arbeiten (also auch nur einmal senden).

Was mir nicht in den Kopf geht ist, warum hier die RSSI Werte so extrem schlecht sind...
Sender und Empfänger (MAX) sind auf der gleichen Etage mit einer Wand (nicht besonders Dick) dazwischen.
Die HM Antenne (baugleich der MAX-Antenne) ist noch im Keller und muss quer durch mindestens 2 weitere Wände senden (funktioniert ohne Probleme).

... sehr merkwürdig ...

Muss ich wohl noch mal drauf rumdenken.

Danke trotzdem!

Gruß
Hajo

MadMax-FHEM · 10 Dezember 2017, 20:51:44

Tja, dann viel Erfolg!

Gruß, Joachim

Sequenzial · 12 Dezember 2017, 08:59:53

Hi nochmal,

ich glaube ich sehe Licht am Ende des Tunnels (hoffentlich kein Zug der mir entgegen kommt):

Nachdem ich meine Verbose auf allen möglichen Devices auf 4 gesetz habe kommen nun doch mehr Informationen zutage.

Irgendwie scheint FHEM (zumindest der MAX Part) den Umzug nicht verkraftet zu haben und versucht ständig mit allen MAX Geräten zu kommunizieren.
Somit ist nach kürzester Zeit die 1% regel erreicht.
Ergo: Max sendet nicht bzw. darf nicht mehr senden.
Empfangen geht, aber senden eben nicht -> also kommt kein ACK.

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

Jetzt sehe ich 2 Möglichkeiten:

- CUL FW mit gr. Credit nutzen (was mich persönlich nicht stören würde, da ich im Umkreis niemanden stören würde)
Das würde aber nur die Symptome angehen nicht die Ursache.

- Die Ursache des Problems finden
was ich lieber machen würde, nur wie ?

Alles was mit Max zu tun hat löschen und "restart from scratch"?

Gruß
Hajo

Sequenzial · 13 Dezember 2017, 11:10:17

Moin,

so, den Credits Kram kann man machen, kann man aber auch lassen.
(hab ich probiert, geht, bringt aber keine Lösung -> also wieder zurück zur legalen 1% Regel),

Was hab ich getan:
- CUL_MAX in FHEM gelöscht,
- Kontakt in FHEM gelöscht,
- Kontakt auf Werkseinstellung gesetzt (Batterie raus, Pairingknopf festhalten und dabei die Batterie wieder einlegen - > Knopf halten bis LED blinkt),
- CUL_MAX neu erstellt (selbe ID wie zuvor),
- CUL_MAX Pairing = 1,
- Kontakt gepairt
Im Log steht das der Kontakt pairen will. Es passiert aber nix.

Dann hab ich mir überlegt, dass FHEM vielleicht irgendwo unter der ID was ablegt (vielleicht kann das jemand bestätigen?).
Am nanoCUL und den Antennen kann es wohl nicht liegen (alles mehrfach getauscht).

Also alles auf links krämpeln...

Zumindest hat folgender Ansatz das Problem gelöst:
- CUL_MAX in FHEM gelöscht,
- Kontakt in FHEM gelöscht,
- Kontakt auf Werkseinstellung gesetzt (Batterie raus, Pairingknopf festhalten und dabei die Batterie wieder einlegen - > Knopf halten bis LED blinkt),
- CULMAX neu erstellt (NEUE ID !!! / neuer Name),
- CULMAX Pairing = 1,
- Kontakt gepairt
Im Log steht das der Kontakt pairen will. Pairing klappt.
Läuft. ACK kommt sofort.
ECO Taster angelernt: alles ok!
Sogar beim Garagentor mit RSSI von >100.

Muss ich das jetzt verstehen?
Wo werden denn noch Daten über die Geräte angelegt. Konnte dazu nix finden.

Gruß
Hajo

MadMax-FHEM · 16 Dezember 2017, 12:31:32

Hi Hajo,

sorry war länger unterwegs...

Eigentlich sollte sich in fhem nichts gemerkt werden, sofern sauber aus der cfg gelöscht wurde: deleteThisDevice und save config...

Leider kann ich nicht sagen ob dein Vorgehen normal ist, da ich MAX! zu wenig bzw. nicht wirklich kenne, hatte nur mal kurz mit MAX! begonnen, bin dann aber relativ schnell zu Homematic gewechselt (die Wandthermostate von MAX! haben keine Luftfeuchte)...

Aber wenn es jetzt geht: gratuliere!

Viel Spaß noch, Joachim