Temperatur-Scanner für MAX-Thermostate

Begonnen von John, 12 März 2013, 09:44:59

Vorheriges Thema - Nächstes Thema

JHo

Hallo Heiko,

eigentlich suche ich ja selber Hilfe, aber:hast Du denn irgendein Wochenprofil auf den Heizthermostaten? Das sollte in den Readings vom Thermostat stehen.

Viele Grüße,
Jan

1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

Kopterframe

Hallo Jan.
Eigentlich habe ich sie mal rein geschrieben, denn sie laufen ja auch outage weiter.
In den Readings stehen sie nicht, komisch?
Wird das benötigt?
Heiko
FHEM aufRaspberry/ Cube_Max mit Culfw/  Cul_FS20
Max Thermostate/ Wandthemostat/Eib KNX

JHo

Hallo Heiko,

die Fehlermeldung aus Deinem Log lässt stark vermuten, dass der Scanner ohne Wochenprogramm nicht arbeiten mag. Beide Betriebsmodi vom Scanner nehmen ja in gewisser Weise Rücksicht auf Weekprofile-Einträge, daher wundert mich das nicht, dass der Scanner ohne einen Eintrag nicht so recht mag. Stell doch einfach mal spaßeshalber drei Zeitintervalle am Tag ein und probiere es dann nochmal.

Bei mir steht in einem Thermostat bei den Readings unter "Valve" dann z.B.
weekprofile-0-Sat-temp 16.5 °C / 18.0 °C / 17.5 °C / 16.5 °C
weekprofile-0-Sat-time 00:00-07:00 / 07:00-07:45 / 07:45-22:00 / 22:00-00:00


Viel Erfolg,
Jan
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

ChrisW

#768
Ich setze bei Abwesenheit immer alle MAX Geräte auf ECO ... und wenn ich zurück bin wieder auf AUTO bekomm ich da ein Provlem bei dem Temperatur Scanner ? Er muss dafür ja immer hin und her wechseln ..
Gibt es da eine Lösung ?

EDIT:
Bei dem DesiredChange bleibt der Mode erhalten ? ALso wenn ich weg bin und ECO gesetzt wird und die Geräte auf 16c stehen wechselt er immer 0,5c hin und her ? Und auch im Automode ??

So sollte es ja keine Störung der An / Abwesenheits anpassung geben ?
Oder sehe ich das falsch ?
Raspberry PI3 mit allem möglichen.

Kopterframe

Hallo Jan,
Habe es mal neu rein geschrieben. Nun geht es.
Schon komist.
Danke Heiko
FHEM aufRaspberry/ Cube_Max mit Culfw/  Cul_FS20
Max Thermostate/ Wandthemostat/Eib KNX

Joseph

same Procedure !
nach Aktivierung von MAXScanner. (FHEM 5.7 auf RaspPi Jessie)
alle Versuche bisher gescheitert die Fehlermeldung:
MaxScanner MAX_1313e9 Work.879 !! weekprofile is not available
zu beseitigen, sogar Wochenplan "Work.879" angelegt.
Keine Chance.

Habe jetzt auch keine Idee mehr.

Joseph

Nach Update ist die Fehlermeldung verschwunden.
Loghinweis:
- Warning master device has no week profile
- MAX: invalid value for reading .weekprofile ...... Forcing to .........

freundliche Grüße
Joseph

JHo

Hallo Joseph,

hast Du dem Heizkörperthermostat, auf dem der Scanner laufen soll, ein Wochenprogramm zugewiesen (set xyz weekprofile <tag>... siehe wiki/commandref, muss dann aussehen wie von mir oben gepostet)? Ansonsten kann der Scanner nicht funktionieren, siehe Wiki.

@ChrisW, Kopterframe, stgeran: bei mir funktioniert der Scanner und beachtet die DesiredChange-Einstellungen, wenn ich vor der Definition der jeweiligen Einstellung zum zu scannenden Wandthermostat dem Thermostat erst noch die Attribute beibringe:

attr Heizung.Kuechenwand userattr scnProcessByDesiChange:0,1 scnShutterList scnModeHandling:NOCHANGE,AUTO,MANUAL

danach dann:
attr Heizung.Kuechenwand scnProcessByDesiChange 1
attr Heizung.Kuechenwand scnModeHandling AUTO

und er arbeitet wie gewünscht, zumindest nach meiner bisherigen Beobachtung. Muss natürlich bei jedem Heizkörperthermostat angegeben sein, was gescannt werden soll. Könnt Ihr das bitte mal bei Euch prüfen? Wenn es klappt, sollten wir den Wiki-Eintrag an dieser Stelle aktualisieren, das ist nicht klar.

Nach wie vor nicht gelöst ist das Problem, dass der Scanner sich aufhängt, wenn er "ein zweites Mal gestartet wird", weil die FHEM-Config neu gespeichert und eingelesen wird. Da hilft bei mir nur "shutdown restart".

Grüße,
Jan
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

Joseph

Danke IHo, für die Nachricht. Scanner funktioniert soweit.
Hinweis zum Problem: fhem.cfg -Aufruf - Scannerkollision - Shutdown restart
Zusätzlich zu dem von Jan beschriebenen Problem wird die Scannerdefinition aus der fhem.cfg entfernt
(vmtl. autocreate Reaktion).

Grüße
Joseph

Odin

Hallo,

ich habe eine Frage zum Scanner, bzw. ob ich etwas falsch mache.

Ich habe 4 Thermostate in 3 Räumen, diese laufen zum Großteil auf Manuell, da ich sehr unregelmäßig zu Hause bin.

Grundeinstellung sind so:
disable: 0
room: MAX
scnMinInterval: 15
verbose: 1



Den Scanner habe ich ein paar Tage im folgenden Modus getestet:

scnModeHandling: NOCHANGE
scnProcessByDesiChange: 0


Leider kam es öfters dazu, dass der Scanner die Thermostate nicht wieder auf den Modus Manuell umgestellt hat, wenn ich vorher z.B. 20 Grad manuell eingestellt hatte. Das ist nattürlich schelcht, da ich keine Wochenprogramme hinterlegt habe und die Thermostate dann nur 5 Grad im Modus Auto hatten.

Als zweites habe ich dann den mit folgenden Einstellungen getestet:

scnModeHandling: NOCHANGE
scnProcessByDesiChange: 1


Hier habe ich leider auch eine ungute Erfahrung gemacht. Wenn ich z.B. 19 Grad im Modus Manuell eingestellt habe, triggert der Scanner dann 18,5 Grad an. Soweit alles fein, aber beim nächsten triggern geht er nicht wieder auf 19 Grad zurück, sondern verringert wieder um 0,5 Grad auf 18 Grad. Beim nächsten triggern dann wieder um 0,5 Grad auf 17,5 Grad u.s.w.!

Was mache ich falsch? Vorab besten Dank!

PeterKramer

#775
Hallo allerseits,

ich betreibe fhem nun schon eine Weile und bin total begeistert von den vielen Möglichkeiten und Funktionen - ein dickes Dankeschön an alle Beteiligten, die dieses Projekt unterstützen!
Nun habe ich mich vor einigen Tagen näher mit dem Temperaturscanner beschäftigt, diesen als Modul eingerichtet und beobachtet.
Ich betreibe ihn mit den Modi: scnModeHandling: NOCHANGE scnProcessByDesiChange: 1

2 Fragen habe ich:

1) Grundsätzlich funktioniert alles wie beschrieben, was bei mir aber ab und an auch vorkommt, ist das der Scanner die Sollwertänderung mehrmals in eine Richtung ändert, so das der Sollwert treppenförmig in ein Maxima bzw Minima läuft.
Abgefangen wird das bei dem nächstfolgenden Schaltpunkt im Wochenprogramm, finde ich aber ungeschickt und ich möchte auch nicht das Wochenprogramm mit unnötig vielen Schaltpunkten aufblasen.
Kann mir jemand Tips geben, wonach ich suchen muß bzw gibt es einen Workaround für diesen Effekt?

2) Bei längerer Abwesenheit von Zuhause (per FTUI Homestatus) schalte ich mit notify alle Thermostate in den manual mode. Den Scanner deaktiviere ich gleichzeitig mit notify "attr Scanner disable 1" (ich möchte damit verhindern, dass durch den Scanner Sollwerte unkontrolliert in ein Maximum gefahren werden, siehe 1)
Ich bin mir nicht sicher ob das ein vernünftiger Weg ist, Attribute per notify zu ändern, mir ist aber kein anderer Weg eingefallen.
Gibt es eine elegantere Möglichkeit, den Scanner on hold oder standby zu setzen?
Oder kann man einzelne Thermostate vorübergehend aus dem Scannerbetrieb rausnehmen?

Für Anregungen wäre ich sehr dankbar.

Grüße PK
fhem auf RasPi3, FTUI auf Ipad mini, MAX Cube, 5 MAX Thermostate, EnOcean TCM, EnOcean Temperatursensor, ESP8266 Temp. und Feuchtesensor

Odin

#776
Ich weiß nicht ob es an mir liegt oder am Scanner, aber so richtig rund läuft der bei mir nicht (siehe vorletzter Post). Daher habe ich ein simples Shellscript (läuft aller x Minuten als cron) geschrieben, welches den gleichen Zwecks erfüllt. Bei Interesse einfach per PM melden.

Viele Grüße!

Cr0n

#777
Ich versuche nun seit einiger Zeit den Scanner zum laufen zu bringen.

Ich habe einen Max Cube und fünf Basic Thermostate, und betreibe sie derzeit mit der original MAX Windows Software + einer Android App.

Ich betreibe FHEM auf einem RaspberryPi (Als Linux Distribution läuft osmc (raspbian jessie)).
Sowohl Linux als auch FHEM wurden jeweils direkt als erstes aktualisiert und Linux gemäß des How-Tos vorbereitet.

Wenn ich den Cube in FHEM einbinde funktioniert alles wie erwartet und die Thermostate werden automatisch gefunden und hinzugefügt. Die Rückmeldeschleife scheint auch zu funktionieren, denn ich sehe bei den Thermostaten sowohl die korrekte Temperatur (ist/soll) als bin ich auch in der Lage eine neue Temperatur über FHEM einzustellen.

Wenn ich jetzt allerdings den Scanner definiere, taucht dieser zwar sofort auf, bleibt aber im state "? ? ?".
Die Max-Geräte werde dabei von Scanner nicht gefunden und damit verknüpft.
Im Log taucht folgender Eintrag auf:

MaxScanner MaxScanner Initialize.121 Init Done with Version 1.0.0.3 - 07.03.2016

Mit verbose=5 zusätzlich noch

MaxScanner MAX.Scan Get.194 cmd:?.

Hat von euch jemand eine Idee, was da schief laufen könnte?

Cr0n

#778
Moin,

inzwischen läuft es: Nachdem ich den Scanner definiert habe, musste ich erst bei jedem Thermostat das Attribut ScanTemp auf 1 setzen, die Konfiguration speichern und FHEM neustarten. Dann hat der Scanner die Thermostate mit ScanTemp=1 gefunden und auch nur diesen Thermosaten die neuen entsprechenden Attribute gegeben. Nun steht er im Status "processing".  Mal schaun, ob das jetzt klappt wie es soll. Wahrscheinlich schon.

Jedenfalls habe ich, während ich mir angeschaut habe wie das Modul so funktioniert, einen Tippfehler in einer Textausgabe in Zeile 739 gesehen:

'ns:' . FmtDateTime($sdNextScan) . ' strDesiTime:' . $strDesiTime . ' Is Mode DesicChange:' . $boolDesiChange;


"DesicChange"

LG

fhem_f

Hallo Matthias,

sowas wollte ich auch immer mal einbauen, weil die Verbindung nach Neustart nicht immer sauber aufgebaut wird oder doch mal verloren geht. Klappt super!

Zitat von: matze1986 am 21 April 2016, 21:47:31

define CUL_reopen DOIF (([CUL_1]) eq "disconnected") (set CUL_1 reopen, set CUL_1 reopen, set  CUL_1 reopen)
attr CUL_reopen do always
attr CUL_reopen wait 5:10:10



Danke

Christian