[gelöst] rferror nach associate zwischen WT und HT

Begonnen von bg1704, 16 Oktober 2015, 11:51:23

Vorheriges Thema - Nächstes Thema

bg1704

Hallo,

ich habe ein WT mit HT. Die Inbetriebnahme macht Probleme. Ich bekomme am WT immer einen rferror wenn ich das WT mit dem HT assoziiere (beide Richtungen). GroupId wurde vorher bei beiden gesetzt. Wochenprogramm ist im WT gesetzt.
Der rferror kommt immer erst NACH dem gegenseitigen assoziieren. Habe schon mehrfach auf Werkseinstellungen gesetzt - ohne Erfolg. Habe ich schon den Raum gewechselt weil ich dachte es gibt Störungen - ohne Erfolg. In einem anderen Zimmer läuft es einwandfrei mit der gleichen Kombination.

Hat jemand noch eine Idee was ich versuchen kann?

Rince

Ja.
Warten. Dann nochmal probieren.

Wenn man ein Device an fhem anlernt, gehen ziemlich viele Credits drauf. Ist mir vorgestern bei der Installation von 8 Fensterkontakten aufgefallen.

Könnte mir gut vorstellen, dass sowohl dein CUL als auch einzelne Geräte bei den diversen Versuchen ans Sendelimit gestoßen sind.


Die Credits vom Cul kannst du über get CULNAME credit10ms (oder war es credits10ms) anzeigen lassen. Allerdings verrät dir das nur, was fhem meint. Die einzelnen Geräte können auch für sich beschließen, das Sendelimit vorübergehend erreicht zu haben.
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

bg1704

#2
Ich kann es mir mittlerweile nicht mehr mit so etwas vorstellen.
Selbst wenn ich die Batterie am WT entferne und wieder einlege. Dann ist mal kurz der rferror weg, aber kurze Zeit später kommt er wieder.
Gibt es weiter Möglichkeiten zur Untersuchung?

Wie bereits gesagt habe ich schon mehrfach Werkseinstellungen bei allen gemacht. Ich habe auch immer schön gewartet, damit ich nicht an das Sendelimit komme (ausser bei Wochenprogramm übertragen an WT)

willyk

Batterien austauschen. Ist mir auch schon passiert, danach war es wieder OK.
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

bg1704

Zitat von: willyk am 16 Oktober 2015, 16:26:36
Batterien austauschen. Ist mir auch schon passiert, danach war es wieder OK.

Danke für den Vorschlag. Ich habe bereits das Wandthermostat + Heizthermostat komplett getauscht.

Habe heute nochmals 2 Stunden investiert. Vor jedem Befehl den Raspi vom Strom getrennt und neu gestartet, damit ich Credits habe - ohne Erfolg.
Sobald ich mit associate beginne am Wandthermostat mit z.B. Fensterkontakt kommt rferror. Den Fensterkontakt habe ich noch nicht getauscht, vielleicht probiere ich das noch, sonst weiß ich nicht mehr weiter...
Das macht mich echt wahnsinnig.

Rince

ZitatVor jedem Befehl den Raspi vom Strom getrennt und neu gestartet, damit ich Credits habe

Bist du sicher, das das hilft?
Zumindest die HM Komponenten werden beim Start von fhem abgefragt, was erst mal viel Funklast erzeugt. Ob das bei Max auch so ist, weiß ich allerdings nicht.

Auch weiß ich nicht, ob wirklich der Zähler zurück gesetzt wird, nur weil du die Batterien rausnimmst.


Ich würde ja wirklich nix mehr tun heute. Setz die Geräte zurück und lass alles bis morgen früh (!) in Ruhe.

Dann frag morgen deine Credits vom Cul ab. Bei >900 leg los. Und schau nach jedem Anlern/Associatevorgang, wie viele du noch hast. Bei >300, mach Pause bis sie sich wirklich wieder erholen.
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

neckartown

Habe das selbe Problem mit 2 WT. Benutze aber den Max!Cube zum steuern. Tritt also auch ohne Cul und ohne fhem auf. Auffällig: passiert nur mit WT+. Mit den alten WT (ohne +) seit mittlerweile 3 Jahren kein Problem, mit teilweise noch den Original Batterien. Im Elv-Forum gibt es noch ein paar threads wegen Verbindungsproblemen mit dem WT+. eq3 Antwortet immer nur mit der Standard Antwort. Lösung nicht in Sicht.

Gesendet von meinem SM-P600 mit Tapatalk

RaspberryPi3 mit SSD, 2xCSM über CP2102 an USB (FS20, MAX!), 2xWLAN miniCUL (locutus), mySensors LAN-Gateway, HM-MOD-RPi-PCB, MAX!Cube mit 7xWT 9*FK 9*HT Eco-Taster, diverse FS20 + HomeMatic, 2xBroadlink RMMINI, in Arbeit: alexa-fhem, ha-bridge, HUE

bg1704

Vermutlich komme ich der Sache näher. Das WT hat eine andere Bezeichnung auf der Rückseite als die 2 wo funktionierten. Anscheinend wurde mir hier zweimal eine alte Hardwareversion untergejubelt. Die 2 funktionierenden haben die Bezeichnung BC-TC-C-WM-4. Das mit rferror hat BC-TC-C-WM-2.
Ich habe mir nun zum 3. Mal ein WT bestellt. Sobald es da ist, und hoffentlich die richtige HW-Version hat werde ich testen und berichten.
Bin sehr froh mal einen Anhaltpunkt gefunden zu haben!!!

bg1704

Statusmeldung:

Bei dritter Bestellung über einen anderen Anbieter kam auch nur das BC-TC-C-WM-2 :-(
Nun habe ich eine vierte Bestellung bei einem weiteren Anbieter ausgelöst.

Werde berichten

bg1704

Hallo,

ich habe mittlerweile mein WT als BC-TC-C-WM-4 erhalten (nach 4 Bestellungen). Voller Vorfreude Inbetriebnahme gemacht. Ergebniss: rferror kommt immer noch. Ich weiß jetzt nicht mehr weiter.
Habe sogar noch das HT und den FK ausgetauscht - ohne Erfolg.
Ich kann es mir nicht mehr erklären, da ich 2 weitere Räume mit gleicher bzw. sogar größerer Installation habe, welche einwandfrei funktionieren.
Leider funktioniert durch den rferror die Kommunikation zwischen WT und HT nicht korrekt. Der Temperatursollwert wird nicht zuverlässig übertragen.
Das alles ist sehr ärgerlich und hat mich bereits viele viele Stunden gekostet (Rücksetzen auf Werkszustand und wieder versuchen...). Solangsam glaube ich, daß FHEM sich den Fehler irgendwo speichert, da ich ja schon alles ausgetauscht habe ?!? Beim Werkszustand zurücksetzen kommentiere ich die Geräte aus. Wenn wieder neu gepaiert wurde lösche ich den Autocreate und kommentiere die Geräte wieder ein. Das mach ich doch richtig, oder?

Kann jemand in meiner Verzweiflung noch Ideen einwerfen?

willyk

Wenn du fhem im Verdacht hast, dann lösche die devices mit "delete", mach einen shutdown und schaue in fhem.save nach, ob die wirklich weg sind. So sollten alle "Rückstände" weg sein.

Danach die Geräte wieder an fhem anlernen, dann untereinander pairen. Dann sollte es gehen.

rferror ist allerdings ein internal value, dieser wird in der fhem.save nicht gespeichert. Deswegen kann ich mir nicht richtig vorstellen, dass das damit zu tun haben soll.

Neulich hatte ich mal die Situation, dass ein HT mit rferror reagiert hat, obwohl der zugehörige WT stromlos war (Batterie alle). Bist du denn sicher dass die anderen Max-Geräte alle richtig funktionieren?

Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

bg1704

Zitat von: willyk am 20 November 2015, 11:37:30

Neulich hatte ich mal die Situation, dass ein HT mit rferror reagiert hat, obwohl der zugehörige WT stromlos war (Batterie alle). Bist du denn sicher dass die anderen Max-Geräte alle richtig funktionieren?

Gruss
willyk

Ja bin mir sicher dass die anderen Max-Geräte richtig funktionieren. Habe schon alles getauscht und etliche Werkszustände hinter mir. Tatsächlich hatte ich auch bei einem HT schonmal einen rferror. Dann habe ich Werkszustand gemacht und neu angelernt, und es war weg. Beim WT schaffe ich es einfach nicht. Meistens beginnt der rferror beim Einspielen des Wochenprogramms...


bg1704

Hallo,

mal wieder ein Update über den Kampf mit dem WT:

Neue Vermutung ist Störsender in der Nähe. Ich habe mir so etwas bestellt =
http://www.stall.biz/?project=868mhz-funksignal-ansehen-mit-dvb-t-stick

Hat jemand Erfahrung mit so etwas?

Grüße

bg1704

#13
Hallo,

also das mit dem Funksignal prüfen brachte mir leider keine neuen Erkentnisse.
Bei der Inbetriebnahme des Wandthermostat habe ich folgende Fehlermeldungen:


2015.12.04 20:09:39 2: MAX: Invalid value  for READING groupid on MAX_HT_KiZi. Forcing to 0
2015.12.04 20:09:39 2: MAX: Invalid value  for READING groupid on MAX_WT_KiZi. Forcing to 0
2015.12.04 20:10:00 1: PERL WARNING: Use of uninitialized value $args[0] in numeric eq (==) at ./FHEM/10_MAX.pm line 702.
2015.12.04 20:10:00 1: PERL WARNING: Use of uninitialized value $args[0] in numeric ge (>=) at ./FHEM/10_MAX.pm line 705.
2015.12.04 20:10:00 2: Invalid WallThermostatState packet
2015.12.04 20:10:00 1: PERL WARNING: Use of uninitialized value $desiredTemperatureRaw in bitwise and (&) at ./FHEM/10_MAX.pm line 736.

Woher könnten diese PERL WARNING Meldung herkommen. Ich vermute durch das Invalid WallTHermostatState packet.

Der rferror kömmt übrigens immer erst wenn das WT mit dem HT associated wurde.

Jemand eine Idee?


bg1704

Hallo Leute,

es sieht so aus als hätte ich des Rätsels Lösung nach wochenlanger verzweifelter Suche: Autocreate abgeschaltet = kein rferror.

Es ist mir nach dem Rücksetzen der Werkseinstellungen aufgefallen, daß das WT automatisch aufgenommen wurde ohne am WT den Pairmode zu aktivieren.
Nun habe ich den Autocreate ausgeschaltet und keinen rferror mehr. Anscheinend hatte sich das WT immer versucht nochmal per Autocreate anzumelden, war aber bereits vorhanden und kam so in den Störmodus. Ich schaltet auf jeden Fall das Autocreate nicht mehr ein.

Vielleicht kann mir jemand erklären warum es nur bei dem Wandthermostat in diesem Raum passiert. In den anderen Räume laufen die WT`s problemlos. Sogar bei Einsatz eines anderen WT`s (neu bestellt) kam es zum rferror. Ist vielleicht noch ein Fehler in der Software von FHEM?

Jetzt bin ich sehr froh den Fehler gefunden zu haben (auch wenn ich nocht nicht weiss warum). Somit klappt jetzt auch die Verbindung zwischen WT und HT. Und es wird nach der Temperatur des WT`s geregelt.