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:
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:
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 ...
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 ...
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
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
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
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)
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...
IODev CUL_MAX
LAST InputDev CUL_MAX
Müsste im CUL_MAX nicht eigendlich stehen mit wem er alles gepairt ist?
Gruß
Hajo
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"...
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
Hi,
hat leider den selben Effekt:
Ich hab den Notify angepasst und wieder aktiviert:
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
Tja, dann viel Erfolg!
Gruß, Joachim
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
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
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