Z-WavePlus Thermostat Eurotronic Spirit: Schrittweise Inbetriebnahme

[rudolfkoenig]

Schaut fuer mich so aus, als ob autocreate deaktiviert waere. z.Bsp, weil kein autocreate definiert ist, oder einer der Attribute disable, ignoreTypes oder autocreateThreshold gesetzt ist.

[curt]

Schaut fuer mich so aus, als ob autocreate deaktiviert waere. [...] ignoreTypes [...] gesetzt ist.

Ja, das habe ich doch gesagt:

Das Problem ist das Attribut "irgnoreTypes" bei autocreate.

Wir haben entweder ein Missverständnis oder ich habe etwas falsch verstanden, das sollten wir mal genauer aufdröseln:
https://wiki.fhem.de/wiki/Fremdger%C3%A4te_ignorieren erklärt mir unter Pkt. 3, dass ich mir die wirklich großen Mengen der Devices der Nachbarn via "ignoreTypes" vom Hals halten könne. Und wenn es so eine Option gibt, darf man die auch nutzen: Ich ging bis gestern davon aus, dass selbstverständlich die nicht zu ignorierenden Devices dem autocreate unterliegen. Oder liegt hier schon (m)ein Missverständnis, mein Fehler?

Ich kann und will nun nicht ausschließen, dass eine der Filterregeln zuschlägt, obwohl sie das gar nicht soll. Ich sehe in meiner Naivität aber keine derartige Regel - der Einfachheit halber zeige ich mal mein autocreate-Device):

Code Auswählen Erweitern


define autocreate autocreate
attr autocreate autosave 0
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate ignoreTypes TRX_.*|RUBICSON_.*|TFA_.*|VIKING_.*|TH.*|Hideki_.*|IT_.*|BTHR.*|WT.*|SD_.*
attr autocreate room 99 System


Also aus meiner recht naiven Sicht sollte mit genau diesen Regeln eine Inklusion eines "Z-Wave-plus-Eurotronic Spirit Thermostat" problemlos gelingen. Das funktioniert aber nicht.

Nochmals präzisiert: Wenn ich "ignoreTypes" für die Zeit der Inklusion rausnehme, geschieht die Inklusion in 2..3 sec.

[Deckoffizier]

Hallo curt,

Schuss ins Blaue....

Ich kann und will nun nicht ausschließen, dass eine der Filterregeln zuschlägt, obwohl sie das gar nicht soll.

bei Auswahl attr autosave folgender Text

autosave
Nach der Erzeugung eines neuen Gerätes wird automatisch die Konfigurationsdatei mit dem Befehl save gespeichert. Der Standardwert ist 1 (d.h. aktiviert), eine 0 schaltet die automatische Speicherung aus.
Achtung: Dieses Attribut ist unerwünscht, bitte stattdessen das global autosave Attribut verwenden.

MfG

Hans-Jürgen

[krikan]

Der ignoreTypes - Attributwert

TRX_.*|RUBICSON_.*|TFA_.*|VIKING_.*|TH.*|Hideki_.*|IT_.*|BTHR.*|WT.*|SD_.*

schließt die autocreate-Anlage von Devices mit dem Namen ZWave_THERMOSTAT_id und damit die Device-Anlage für das Spirit aus.

Bei dem Attributwert

Code Auswählen Erweitern

(TRX_.*|RUBICSON_.*|TFA_.*|VIKING_.*|TH.*|Hideki_.*|IT_.*|BTHR.*|WT.*|SD_.*)
würde ignoreTypes beim Spirit afaik nicht matchen. Vielleicht ist das eher gemeint.

Das Wort "Types" im Attributnamen ist übrigens etwas irreführend, da der Gerätename geprüft wird und nicht der Typ.

Gruß, Christian

[curt]

TRX_.*|RUBICSON_.*|TFA_.*|VIKING_.*|TH.*|Hideki_.*|IT_.*|BTHR.*|WT.*|SD_.*

Der ignoreTypes - Attributwert schließt die autocreate-Anlage von Devices mit dem Namen ZWave_THERMOSTAT_id und damit die Device-Anlage für das Spirit aus.

Autsch, böse Falle. Ich ging davon aus, dass mit dem Anfang des Strings verglichen wird. Und wenn man wahlfrei innerhalb des Strings verglichen werden soll, man .*TH.* zu nehmen habe.

Danke für den Hinweis.

[rudolfkoenig]

Ich ging davon aus, dass mit dem Anfang des Strings verglichen wird.

Der Code im autocreate.pm packt zwar den Inhalt von ignoreTypes in ^$ (genauso wie notify,FileLog,etc), aber ohne Klammer passiert nicht das, was man erwartet.

[krikan]

Rudi, gehört der Link im Zitat hier wirklich hin? Ich verstehe den Zusammenhang nicht. 

[rudolfkoenig]

Danke fuer den Hinweis, natuerlich nicht, habs geaendert.
Wie man sieht, kaempfe ich noch mit meinem neuen Computer

[curt]

Freunde der warmen Stube,
mal weiter zum eigentlichen Thema (ggf. benenne ich das nachher entsprechend Threaddrift etwas um).

(M)ein Problem ist ja immer: Da hat man so ein schönes neues Spieldings und weiß gar nicht, was das so alles in Zusammenhang mit FHEM kann - und wie ich das in FHEM mir erstmal ansehe. Und dann gibt es (zu Recht) oft Hinweise, dass das Spieldings irgendwie auch Murks sei. Na jedenfalls hatte ich Glück: Ein sehr freundlicher Mensch nahm mich per PN an die Hand und zeigte seine scheinbar simple, aber tolle Konfiguration. Vielleicht zeigt er das auch noch hier im Thread, späteren Lesern wäre es zu wünschen.

Übrigens fehlt bei manchen Thermostaten das Reading "thermostatMode" ... keine Ahnung warum. Da ist es wieder - mein Problem: Wegen Amazon in mehreren Tranchen bestellt, verschiedene Verpackungen zudem: Es könnte schon sein, dass verschiedene Versionen vorliegen. Aber das sieht man den Dingern ja auch in FHEM nicht an. Oder - ich habe bei den fraglichen Thermostaten irgendwas vergessen, ein GET oder ein SET. Sowas ist als Widerspruch kaum auflösbar.

Bitte nicht falsch verstehen: Ich habe niemanden kritisiert, das liegt mir fern. Ich weiß nicht nur, wie toll FHEM (als Ergebnis der Arbeit vieler) ist, ich weiß auch, dass jeder hier schreibt ohne das bezahlt zu bekommen. Danke an alle!

[MadMax-FHEM]

Vielleicht zeigt er das auch noch hier im Thread, späteren Lesern wäre es zu wünschen.

Warum nicht du!?

Gruß, Joachim

P.S.: dass "vermeintlich" gleiche ZWave Geräte dann doch (minimal) "anders" aussehen habe ich auch schon bemerkt. Z.B. Fibaro Bewegungsmelder. Je nachdem wann ich die wo bestellt habe etc. Bis hin zu ganz anderem "Verhalten" bzgl. Motion/NoMotion bzw. "Alarmauslösung"... Allerdings sollte man evtl. sowas wie FW sehen in fhem!? Evtl. gibt es ja da einen Unterschied...

[Beta-User]

Vielleicht zeigt er das auch noch hier im Thread, späteren Lesern wäre es zu wünschen.

Evtl. gäbe es eine weitere Variante, wie man sowas "verstetigen" könnte...:
https://forum.fhem.de/index.php/topic,114109.0.html

[curt]

Evtl. gäbe es eine weitere Variante, wie man sowas "verstetigen" könnte...:
https://forum.fhem.de/index.php/topic,114109.0.html

In dem dortigen Beitrag steigst Du für meine Begriffe zu hoch ein, damit hast Du mich als möglichen Zulieferer/Mitarbeiter schon verloren: Da gibt es offenbar XML-Files für jedes Gerät, in Deinem Beitrag wird aber nicht klar, ob das "weggefundene" XML sind oder irgendwas FHEM-spezifisches. Und so zieht sich das durch den kompletten Beitrag: Du erklärst nichts, setzt aber voraus. Klar kannst Du sagen "musste halt mal googlen" - aber selbst mein Tag hat nur 24 Stunden.
Ich würde mal sagen: Du verlierst damit jede Menge Träger von Erfahrungen. Nimm es nicht persönlich, es ist einfach so.

Warum nicht du!?

Ich mache zunächst mal was ganz anderes, ich fasse zunächst meine Erfahrungen allgemein zusammen - speziell kann ich später noch vortragen.

Als erstes muss man bedenken, dass niemand fortlaufend die gleichen Geräte kauft, es wird immer riskantes Neuland sein!

Summa: Z-Wave-Geräte sind stabil, robust, machen im Betrieb wenig Ärger. Es gibt allerdings Wandprobleme.

Tatsächlich scheint mir die Einstiegshürde für Z-Wave im Zusammenhang mit FHEM recht hoch: Zwar gibt es einen recht guten allgemeinen Wiki-Artikel zu Z-Wave sowie zu einigen konkreten Geräten. Aber im Grunde haut man für eine neue Funktion, neues Gerät  immer blind 50 Euro auf den Kopf, man kauft die Katze im Sack. Es kann das machen, was man will, das muss aber nicht so sein.

Einigermaßen dramatisch ist die Inklusion. Mal abgesehen von der autocreate-Falle (siehe oben) ist der Funkverkehr bei der Inklusion offenbar instabil. Entfernungen im Normalbetrieb werden während der Inklusion nicht ansatzweise erreicht, das zu inkludierende Gerät muss bezogen auf den Z-Wave-FHEM-Baustein im gleichen Raum, ca. 3m entfernt sein. (Bei fehlerhafter Inklusion wird es dramatisch: Man muss via FHEM dem Z-Wave-FHEM-Baustein klarmachen, dass UNKNOWN_DEVICE gelöscht werden muss.)

Damit sind wir beim Thermostat (ich habe acht, also reichlich Übung): Den habe ich also neben dem FHEM-Server in der Hand. Falls die Inklusion gelingt, sind flinke Füße angesagt. Denn der Thermostat hat auch Ideen und quengelt rum: Er will nun unbedingt einen Adapterlauf (der Motor testet mal das Ventil des Heizkörpers) - also rennen und anbauen und Knöpfchen drücken ... und beten.

Dann ist es wichtig, den kompletten Zirkus aus https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F durchzuziehen:

get <device> associationAll
get <device> configAll
get <device> versionClassAll
get <device> mcaAll
get <device> wakeupInterval

Denn sonst ist FHEM bezogen auf das neue Device blind. Das sagt Dir nur niemand (wenn ich meinen treuen Freund @Beta-User nicht hätte ...) - anzumerken ist an der Stelle, dass nicht jedes GET bei jedem Gerät vorhanden ist.

Aus meiner ganz naiven Sicht:
Wünschenswert wäre, wenn die o.g. Befehlskette ganz automatisch am Ende der Inklusion ausgeführt würde!
Hinweis dazu: Mein PN-Freund meint, dass es erfahrungsgemäß wichtig sei, vermittels "sleep 3" Pausen einzulegen, um dieses Netz nicht zu überlasten.

Warum dieses, warum mein Vorschlag, diese Befehlskette als Teil der Inklusion auszuführen?
Weil niemand jede Woche neue Z-Wave-Geräte kauft. Weil man immer wieder mit Z-Wave-Geräten vor der gleichen Baustelle steht: Einen Prozessweg aus zig Wiki- und Forenartikeln rauszusuchen. Das ist nervig und hat vor allem eine sehr hohe Fehlerquote.

Die einigermaßen vernünftige Integration von Thermostaten in FHEM ist dann die nächste Baustelle: Was kann man sich sinnvollerweise anzeigen lassen? Wie mache ich eine Temperatursteuerung? Wie mache ich das mit dem "Fenster-auf - Fenster-zu"? Also Fenster hat jeder, eigentlich kann es nicht sein, dass jeder sich mühselig durch notify- und DOIF-Themen kämpft. Ja, habe ich dank einiger Hilfe. Offen ist noch das, was @Deckoffizier da mit readingList und setlist macht - beide sind nirgendwo hinreichend (mit Beispielen!) beschrieben. Vermutlich so eine Art Runterklappmenü - aber das rate ich nur.

Um mal zu den positiven Dingen zu kommen:
Also wenn es (Z-Wave) läuft, dann läuft es. Zwar meint mein PN-Freund, dass man jeden Befehl nach "sleep 3" nochmals absetzen müsse. Mir war noch gar nicht aufgefallen, dass es da ein Problem geben könnte: Ich habe im zweietagigen Haus 14 aktive Z-Wave-Steckdosen, die scheinen für hohe Stabilität des Z-Wave-Netzes zu sorgen.

Dafür ist allerdings notwendig, dass "set neighborUpdate" für jedes Z-Wave-Gerät ausgeführt wird. Auch so eine Baustelle: Man freut sich ohne Ende, dass der Thermostat da unten läuft - auf diese Idee kommt man gar nicht ...

Im Grunde bräuchte man im Raum ZWave einen Knopf "neighborUpdate", den man alle vier Monate mal drücken kann: An jedes Gerät geht der Befehl. Immer mit "sleep 3" dazwischen.

Als problematisch stellt sich der Übergang von Haus zu Garten dar: Ich habe Z-Wave-Steckdosen im Garten. Das ist nun aber ein Niedrigenergiehaus mit geilen Fensterscheiben - das geht es grad noch so. Wenn aber die Rolläden (auch Isolation) runter sind, dann wird das wacklig. Und das selbst mit einem Z-Wave-Repeater-Stecker, den ich auch habe.

[Beta-User]

Vorab mal Sorry, wenn dir der verlinkte Thread jetzt nicht unmittelbar weitergeholfen hat.

Im Kern wollte ich sagen: Hier im Forum bei passender Gelegenheit eine funktionierende Konfiguration (und optimalerweise den Vorgehensweg bis dahin und das, was sich ggf. daran anschließt) zu posten ist ein guter Anfang, aber was wir mAn. eigentlich brauchen, ist ein strukturierter Erfahrungsaustausch _pro Gerät_: "FHEM-ZWaver aller Länder, tauscht euch aus!"...

Das Problem ist in der Tat, dass FHEM erst mal "nichts weiß", also vor der Bestimmung des Models (mit Hilfe der von außen kommenden, weltweit und in fast allen Systemen (also auch der Lösung von Fibaro etc.) verwendeten XML's - der get model-Befehl wird am Ende des Inclusions-Vorgangs afaik abgesetzt) schon gar nicht in der Lage ist, die passenden "Anschlussbefehle" zu ermitteln und erst recht nicht wissen kann, wie der Anwender ein ZWave-Gerät denn verwenden will. Das muss er (fast) immer selber entscheiden.

Genau an dem Punkt setzt dein Problem an, und auch meine Überlegung, OB attrTemplate als Mechanismus denn dazu eine Lösung bieten könnte. Das können ggf. nur Leute beantworten, die in der Materie tiefer drin sind wie wir beide, ich kann von meiner Seite "nur" das Wissen bereitstellen, welche Optionen man mit dem attrTemplate-Baukasten an sich hat. Von daher war mein Post auch (mit) die Aufforderung an den freundlichen pm-Helfer, dieser Diskussion an der einen oder anderen Stelle beizutreten, er scheint jedenfalls auf der ZWave-Seite deutlich weiter zu sein wie ich.

Ansonsten _glaube_ ich nicht, dass das mit dem "immer riskantes Neuland" so sein muß. Bereits heute entspricht das nicht unbedingt ("immer" ist schlicht falsch...) meiner Erfahrung, es ist eben "nur" in Teilen so.

Mal schauen, wie sich die Dinge entwickeln, ansonsten kann ich in Teilen den Frust nachvollziehen, der da zwischen den Zeilen steckt, warum es weder was spezielles zur konkreten Verwendung dieser Thermostate im Wiki gibt noch sowas wie eine (oder mehrere) "Musterlösung/en" für Heizungssteuerung allgemein oder PID20. (Es gibt aber durchaus viele kleine Bausteinchen, die allerdings mAn. irgendwie nicht richtig verzahnt sind).
(Vielleicht ist das eine "einfachere" Baustelle, um die sich mal jemand intensiver bemühen mag?)

PS: FHEM als Gesamtsystem "an sich" wird wegen ein paar attrTemplates kaum einfacher, das ganze Zusammenwirken der Komponenten wird immer komplex bleiben. Das Ziel kann daher kaum sein, jeden "mach ich mal, wird schon werden..."-Anfänger damit "glücklich" zu machen...

[rcmcronny]

Hi,

Ich weiss nicht, ob ich gemeint bin mit dem PM Freund, Kontakt hatten wir zumindest und ich stehe zu meinen Nachrichten

ZWave ist ein Thema, wo man sich bei jedem neuen Gerät erstmal mit beschäftigen muss, mit Glück gibt es schon Infos im Forum hier und man kann daraus für seinen Zweck  alles rauslesen. Wenn nicht oder wenn die Infos unklar sind, dann kann es schnell passieren , das man frustriert ist. Ich habe auch noch so ein Multisensor 6 Zwave liegen, der nicht tat was ich wollte (Falls den Jemand will -> PM (neuwertig , Batterien sind auch da und usb Kabel sollte auch da sein, kann ich gern checken wenn jemand braucht). 
Vielleicht können wir ja auch im Wiki die Infos verbessern, auchdie Templates finde ich als eine Variante die Unterstüzen / helfen kann. Letztlich ist ZWave aber mE kein System, was einfach läuft ohne das man etwas Wissen aufbaut und sich etwas beschäftigt damit. Das ist aber letztlich bei allem so

Das mit den Sleep 3 kommt jedenfalls von mir, und ist darauf begründet, das DOIFs  teilweise Daten von meinen 3 Thermostaten anfordern, weil die es nicht hinbekommen, die zu senden (Firmware Gründe wohl)
Ich hatte da immer Probleme mit NoAck usw das einfach zuvieles gleichzeitig passierte und lass im Forum oder Wiki, das man es serialisieren soll, also nacheinander mit Pausen dazwischen.
Genau das macht das Sleep, was nonblocking ausgeprägt ist, es rennt also im Hintergrund und macht seinen Job. Es dauert vielleicht dann 1-2 Minuten gesamt, aber dafür passt alles

Ronny

[Beta-User]

Den Multisensor kenne ich nicht, aber da ich bisher keine Batterie-ZWaves habe und vermutlich einfach Testhardware für das eine oder andere benötige: Was hattest du dir dafür vorgestellt? (Details gerne per pm; falls jemand anderes was taugliches hat: gerne auch leihweise, das ist allerdings kein Versprechen,  dass ich dann auch zeitnah dazukomme...)

Ansonsten: Wenn du die Konfiguration(-sanweisungen) für den Eurotronic zusammenstellst, kann ich gerne mal versuchen, das zu "vertemplaten", und gehe davon aus, dass curt dann gerne den Tester macht?

Btw.: "firmware" wäre ein anderes Thema, wo wir uns ggf. zusammentun müssen und dem einen oder anderen Hersteller mal auf die Füße treten... (Es gab da auch vor ein paar Wochen einen völlig unbeachteten Thread "user alliance" oder so ähnlich)

Und so wie ich Rudi kenne, ist er auch gerne bereit, im Modul ggf. sinnvolle "Begleitcodes" bereitzustellen, falls das erforderlich wäre. Setzt halt einen "konsolidierten Wissensstand" voraus. Macht ja keinen großen Sinn, wenn man für jede Hardware dann einen "typischen Zoo" von "Begleitmodulen" braucht, nur um diese Hardware zu nutzen...