Mehrere Fragen zur Ersteinrichtung

Begonnen von bismosa, 05 Oktober 2017, 22:13:06

Vorheriges Thema - Nächstes Thema

bismosa

Hallo,

ich versuche gerade meine MAX Heizkörperthermostate Basic (Firmware 1.1) in FHEM einzubinden.
Ich nutze einen selbstbau CULMAX an einem Rasperry PI.

Für einzelne Räume werde ich die Thermostate einzeln koppeln und per FHEM mit dem tollen weekprofile Modul die Timer programmieren. Soweit recht einfach.
1.) Was passiert, wenn mein Raspberry mal wieder die Speicherkarte zerfrisst und für ein paar Tage offline geht? Regelt der Thermostat eigenständig nach dem eingestellem Profil?

Nun aber etwas kompliziertere Fragen...
Mein Setup im Wohnzimmer/Essbereich/ offene Küche:
1x Wandthermostat+ (Firmware 1.0) (WT)
4x Heizkörperthermostate Basic (Firmware 1.1) (HT)

Hier habe ich schon vor ein paar Tagen alle HTs mit dem WT gekoppelt. Insgesamt scheint sich der Raum trotz arg unterschiedlicher Heizungen einigermaßen gleichmäßig zu erwärmen. So richtig kalt war es ja jetzt noch nicht. Ich bin mal gespannt, wie es in unserem Altbau dann wird.

Was ich eigentlich schade finde, ist so eine fehlende Möglichkeit einzelne Thermostate mal aufzudrehen. Wir haben einen älteren Radiator vor unserem Terrassenfensterelement auf den man sich im Winter auch gerne mal setzt. Drehe ich hier mal den Heizkörper hoch, werden ja alle anderen auch sofort geändert. Auch muss ich den ganzen Raum hochheizen, wenn wir abends nur im Wohnzimmer sitzen.
Mir wäre es eigentlich lieber, wenn der WT nur einen eigentlichen Soll-Bereich (mit Zeitsteuerung) vorgibt, aber die Thermostate selbstständig regeln.

Nun aber zum eigentlichen:
1.) Gibt es eigentlich eine genauere Beschreibung, wie das Regelverhalten der Thermostate ist? Ist der WT ein "Soll und Istwertgeber" und die Thermostate nutzen diesen anstatt den eingebauten Temperatursensor? Wird der Temperatursensor des HT bei der Berechnung mit einbezogen? Mir scheint es so, als ob hier nur eine Ventilposition bzw. die Berechnugnsgrundlage für die Position für alle Thermostate angegeben wird...bisher ist die gemeldete IST-Temperatur und die Ventilposition bei beiden angemeldeten Thermostaten immer identisch. Und die IST-Temperatur auch genau die, die vom WT gemeldet wird.

2.) Ich habe gelesen, das es für den Funktraffic sinnvoll ist, nur den WT mit FHEM zu koppeln? Oder muss auch jeder HT mit fhem gekoppelt werden? Ich würde gerne die Ventilpositionen und Temperaturen in fhem loggen....
3.) Interessant wäre es die IST-Werte in fhem zu erfassen. Bisher bekomme ich aber immer als IST-Wert den Wert des WT!?
4.) Ich habe jetzt mal den WT und 2 HTs mit fhem gekoppelt und diese dann in beide Richtungen mit Associate mit dem WT gekoppelt. Nun komme ich beim WT nicht mehr ins Menü um die Tageszeiten zu ändern?
5.) Im Wiki vom MAX!_Temperatur-Scanner steht, das der Scanner unnötig ist, wenn ein WT eingesetzt wird, da dieser eine detaillierte Kurve des IST-Wertes liefert. Stimmt. Aber wenn ich nur diesen angelernt habe, bekomme ich ja nicht die Temperaturen von den HTs?
6.) Wenn ich die HTs in FHEM angelernt habe, habe ich die Möglichkeit ein valveOffset einzustellen. Somit ist es ja möglich, die Heizungen manuell anzugleichen. Oder bringt das nichts?

7.) Wie und in welcher Reihenfolge muss ich jetzt den WT bzw. die HTs mit fhem koppeln?
Wenn ich es bisher richtig verstanden habe:
a) Koppeln:
fhem-WT
fhem-HT1
fhem-HT2
...
Associate:
WT-HT1
HT1-WT
WT-HT2
HT2-WT2
...
Vorteil: Ich kann in fhem alles mitbekommen, aber eigentlich findet der meiste Funkverkehr zwischen WT+HT statt. Ich kann ebenso eine Temperatur, Wochenprogramme,  valveOffset und meine billigen 433MHz Fensterkontakte benutzen.  Die IST-Temperatur ist aber die vom WT(?)
Nachteil: Am WT(+) kann ich keine Zeiten mehr einstellen

b) Koppeln:
fhem-WT
WT-HT1
WT-HT2
...
Vorteil: Ich kann über fhem eine Temperatur, Wochenprogramme und Fensterkontakte setzen.
Nachteil: ValveOffset ist nicht einstellbar

Stimmt das so in etwa?

Achso...durch Autocreate wurden mir die Geräte mit MAX_145194 etc. benannt. Ist recht verwirrend. Ich kann nun zwar ein Attribut alias eingeben...aber darf ich das Gerät auch umbenennen? Oder gibt es da ggf. Schwierigkeiten?

Sorry...bestimmt recht verwirrend. Aber ich stehe hier irgendwie vor einem riesen Berg fragen...und es ist sehr mühselig alles durch probieren zu ermitteln. Ich hoffe ihr könnt mir da helfen!
Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wzut

Zitat von: bismosa am 05 Oktober 2017, 22:13:06
es ist sehr mühselig alles durch probieren zu ermitteln.
Das stimmt, da ist lesen hier rum Forum viel einfacher. Aber ein bissel Arbeit in Form von suchen muss schon sein.

Bei deinen ganzen Fragen machst du IMHO an zwei Punkten einen Denkfehler :
a. warum um alles in der Welt willst du unbedingt am WT Datum und Uhrzeit manuell einstellen wenn es doch bereits mit FHEM verheiratet ist ? Das ist doch genau der Vorteil, dein FHEM hat i.d.R. eine exakte Uhr und die hat der WT dann auch, also warum diese auf irgendeine Mondzeit verbiegen ?

b. Du musst nicht "unbedingt" das HT an FHEM anlernen nur um den Funkverkehr zu belauschen, d.h. du bekommst alle Werte mit die das Ding so von sich gibt z.B. wenn es mit dem WT redet. Willst du allerdings Werte im HT direkt setzen bzw. ändern , (bsp valveOffset ) dann wird der HT das nur annehmen wenn der Absender ihm als Master bekannt ist - sonst könnte ja der böse Nachbar mit ständigen 5 °C Soll Wünschen kommen ....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

bismosa

Hallo,

danke für die Antwort. Mittlerweile bin ich auch schon wesentlich weiter.

Ich habe nun alle HT und den WT zurück gesetzt und ganz neu angefangen. Auch in fhem habe ich alle Geräte gelöscht und neu begonnen.
Ich habe nun alle Geräte direkt mit fhem gekoppelt und dann jeweils Associate:
WT-HT
HT-WT

Mit einer eindeutigen GroupID klappt das nun.

Ich möchte an dem WT nicht die Uhrzeit einstellen, sondern die Zeiten nach Bedarf anpassen. Aber das ist ja generell nicht mehr möglich, sobald das WT an FHEM angelernt ist. Mittlerweile habe ich das auch in der BA gefunden. Im Abschnitt Reset.

Ich habe das Attribut KeepAuto gesetzt. Ich möchte die Temperaturen bis zum nächsten Schaltpunkt verändern können. Aber halt nur bis zum nächsten Schaltpunkt.
Problematisch ist jetzt noch, das sobald ein Fenster offen war das Thermostat wieder auf den Programmierten Wert zurückspringt. Da habe ich noch keine Idee, wie ich das verhindern könnte.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wzut

dann schau dir mal https://forum.fhem.de/index.php/topic,77678.0.html an,
bin mir allerdings auch nicht sicher ob dann durch Fenster offen/zu der Modus bis zum Ende durch gefahren wird oder das Wochenprogramm gewinnt.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

bismosa

Hallo,

ja...das Modul sieht auch interessant aus. Ich habe es jetzt nicht getestet, da es für meine Familie schon wieder zu kompliziert wird. Es sollte einfach nur eine Temperatur einstellbar sein...oder diese nur am HT verändert werden.
Ich habe jetzt nochmal getestet. Ich muss wohl abstriche machen
1.) Modus "keepAuto" (DesiredChange)
Vorteile:
- Der Automodus wird nie verlassen
- Es kann auf Manuell gestellt werden und diese Temperatur bleibt auch über Schaltzeitpunkte hinweg erhalten
- Es kann ein ECO-Taster eingebunden werden
Nachteile:
- Ständiges verfahren des Thermostates
- Wenn ein Fenster geöffnet wurde, wird die Temperatur afu fix 17°C eingestellt (ich muss aber nochmal versuchen herauszufinden warum das so ist)
2.) Modus ModeChange
Vorteile:
- Der Sollwert kann über fhem und am Thermostat verändert werden und bleibt bis zum nächsten Schaltzeitpunkt erhalten
- Fenster offen wird vom MaxScanner abgefangen und hinterher wird die letzte eingestellte Temperatur wieder übernommen
Nachteile:
- Es gibt wohl keinen Manuellen Modus mehr.
- Steht der HT gerade auf Manuell und fhem fällt aus bleibt der HT auf der Position
- Eco Taster wird nicht unterstützt.

Hmmm...so richtig gefällt mir das nicht.
Ich denke, es wäre insgesamt besser auf die IST-Temperaturen mit dem Scanner zu verzichten...schade.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wzut

Zitat von: bismosa am 24 Oktober 2017, 10:48:50
- Wenn ein Fenster geöffnet wurde, wird die Temperatur afu fix 17°C eingestellt (ich muss aber nochmal versuchen herauszufinden warum das so ist)
Für die 17 °C ist windowOpenTemperature verantwortlich , 17 ist der default Wert. Dieser greift immer wenn durch einen FK das Signal Fenster offen kommt, oder aber der HT selbständig einen Temperatursturz erkennt - in dem Fall ist dann auch
windowOpenDuration entscheidend für die Dauer. Bei der echten FK Meldung bleibt er ewig auf den 17 °C stehen.

Zitat von: bismosa am 24 Oktober 2017, 10:48:50
- Es kann ein ECO-Taster eingebunden werden
-- snipp --
- Eco Taster wird nicht unterstützt.
Den kannst du mit FHEM zusammen immer einbinden und sogar fürs Garagentor missbrauchen, lediglich die Original Software hat da Einschränkungen.

Zitat von: bismosa am 24 Oktober 2017, 10:48:50
Ich denke, es wäre insgesamt besser auf die IST-Temperaturen mit dem Scanner zu verzichten
Ich will die Arbeit von John nicht kleinreden, aber ich hatte den auch nur kurz zum Test in Betrieb.
Heute haben bei mir alle wichtigen Räume ihr eigenes WT und die unwichtigen einen 11€ teuren LaCrosse Temperatur Sensor. Ein weiter Vorteil dieser Lösung ist das die Temperatur nicht mehr direkt am Heizkörper erfasst wird sondern in einem Bereich der für das Wohlbefinden viel relevanter ist ( z.B. Sitzecke im Wohnzimmer )
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

mahowi

Zitat von: Wzut am 24 Oktober 2017, 12:56:00
Ich will die Arbeit von John nicht kleinreden, aber ich hatte den auch nur kurz zum Test in Betrieb.
Heute haben bei mir alle wichtigen Räume ihr eigenes WT und die unwichtigen einen 11€ teuren LaCrosse Temperatur Sensor. Ein weiter Vorteil dieser Lösung ist das die Temperatur nicht mehr direkt am Heizkörper erfasst wird sondern in einem Bereich der für das Wohlbefinden viel relevanter ist ( z.B. Sitzecke im Wohnzimmer )
Dem kann ich nur zustimmen. Ich hatte mal ursprünglich 7 MAX-Thermostate, von denen 5 über den MAX-Scanner liefen. Das hat ständig dafür gesorgt, daß die Credits ausgingen. Mittlerweile erfasse ich die Ist-Temperatur auch über externe Sensoren und habe keine Probleme mehr.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

bismosa

Hallo,

danke für die Meinungen. Ich bin auch schon am schauen, wie ich die Temperaturen sonst erfassen kann. Welche LaCrosse Temperatur Sensoren hast Du?

Zitat von: Wzut am 24 Oktober 2017, 12:56:00
Für die 17 °C ist windowOpenTemperature verantwortlich , 17 ist der default Wert. Dieser greift immer wenn durch einen FK das Signal Fenster offen kommt, oder aber der HT selbständig einen Temperatursturz erkennt - in dem Fall ist dann auch
windowOpenDuration entscheidend für die Dauer. Bei der echten FK Meldung bleibt er ewig auf den 17 °C stehen.

Ich hatte mich hier falsch ausgedrückt. Sorry. Bei dem HT habe ich die WindowOpenTemperature auf "Off". Wenn das Fenster wieder geschlossen wurde, wurde immer wieder auf 17°C gestellt. Obwohl ich manuell auf 21°C vorher gestellt hatte.
Muss ich vielleicht nochmal durchprobieren. Vielleicht hatte sich das auch nur gerade überschnitten. Die Kinder sind halt gerne auf dem Balkon.
Der Temperaturscanner scheint sich dem Problem angenommen zu haben. Wenn ich im Mode-Change Modus bin udn das Fenster wird wieder geschlossen wird kurzzeitig auf die 17°C gesprungen. Der Scanner korrigiert dann auf die letzte Einstellung. Ich habe das hier im Wiki vom Scanner gefunden:
ZitatWenn das Thermostat im Auto-Modus ist und der Fensterkontakt geht von aktiv zu inaktiv (Fenster wieder geschlossen), dann stellt das Thermostat fix 17 Grad ein, also nicht den zuvor eingestellten Sollwert (dieses Verhalten betrachten viele als Design-Fehler).


Eco-Taster:
Zitat von: Wzut am 24 Oktober 2017, 12:56:00
Den kannst du mit FHEM zusammen immer einbinden und sogar fürs Garagentor missbrauchen, lediglich die Original Software hat da Einschränkungen.
Ja. Das nutze ich auch schon. Ich habe mal spaßeshalber bei Druck auf den Eco-Taster eine Sprachdurchsage eingebunden. Dann werden mir vorgelesen, welche Fenster noch geöffnet sind.
Erreichen möchte ich jedoch das die Heizungen dann in den Manuellen (bzw. in den Urlaubs-) Betrieb wechseln und z.B. 17°C halten, bis der Eco-Mode wieder aufgehoben wird.
Wenn ich es bisher richtig verstanden habe dann geht das mit dem Scanner nicht, da dieser ja immer zwischen Auto und Manuell wechselt. Somit würde beim nächsten Schaltpunkt der Eco-Mode wieder aufgehoben werden.

Zitat von: Wzut am 24 Oktober 2017, 12:56:00
Ich will die Arbeit von John nicht kleinreden, aber ich hatte den auch nur kurz zum Test in Betrieb.
Heute haben bei mir alle wichtigen Räume ihr eigenes WT und die unwichtigen einen 11€ teuren LaCrosse Temperatur Sensor. Ein weiter Vorteil dieser Lösung ist das die Temperatur nicht mehr direkt am Heizkörper erfasst wird sondern in einem Bereich der für das Wohlbefinden viel relevanter ist ( z.B. Sitzecke im Wohnzimmer )
Nein, das möchte ich auch nicht. In dem Modul ist viel Know-How enthalten. Siehe auch das Verhalten nach dem Fenster schließen. Außerdem ist es wohl die einzige Möglichkeit bei den Thermostaten regelmäßig die Temperatur auszulesen.

Wäre schön, wenn Du mir einen Tip für die verwendeten externen Sensoren geben könntest.

Danke.
Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wzut

Zitat von: bismosa am 24 Oktober 2017, 13:27:33
Welche LaCrosse Temperatur Sensoren hast Du?
Das ist zwar jetzt hier ein bissel OT ... aber :
Wenn du Interesse an den günstigen und IMHO recht zuverässigen LaCrossse Dinger hast schau dir mal diesen Wiki Artikel an : https://wiki.fhem.de/wiki/JeeLink
Dort ist in der Mitte eine Tabelle der unterstützten Sensoren. Es liegt nun an dir welche Ausführung du möchtest,
die einfachste Bauart ist der TX29-IT  ohne Display und nur Temperatur ( Amzon Preis ca 15€, Conrad 17€),
der nobelste ist der  TX29DTH-IT mit Temp & Luftfeuchte und kleinem Display. Zur Verwirrung gibt es die dann nochmal unter einem TFA Label , dort beginnt die Modellbezeichnung  mit 30.xxx.
Aber ACHTUNG : Die LaCrosse Sensoren arbeiten normalerweise mit 868MHz , bei den TFAs gibt es auch 433 MHz Modelle.
D.h. bevor du welche kaufst (egal wie gut das Sonderangebot ist ) , schau in die Tabelle ob er gelistet ist und wenn ja mit welcher Datenrate. Bsp TX29-IT 17,241 kbps  vs. TX35-IT 9,579 kbps. Passenden JeeLink zm Empfang ( USB oder Wlan)
gibt es recht oft günstig hier im Marktplatz Güter.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

bismosa

Hallo,

danke. Hmmm...also müsste ich für meine 5 Räume mal eben 5x15€+32,50€(Empfänger) = 107,50€ locker machen müssen. Grmpf.
Interessanter wäre da vielleicht ein DHT22. Ich müsste mir dann nur mal Gedanken machen, wie ich das Verkabeln kann...ich befürchte, das meine CAT6 Kabel (die ich teilweise bereits auf Vorrat verlegt habe) zu lang dafür sind.
Schade, das es wohl kaum anders möglich ist  :'(

Mir ist gerade noch eingefallen...ich könnte ja beim Drücken des Eco-Tasters eine Fenster-Offen-Meldung verschicken. Dann bleiben die Heizkörper auch aus. Aber leider im Winter auch ganz aus....

Gruß
Bismosa

1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wzut

wenn du eh CAT 6 Kabel hast dann nimm doch ne OneWire Lösung :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

bismosa

Hallo,
auch wenn es OT scheint. Es passt sehr gut zum Thema. Immerhin suche ich ja nach einer Lösung für meine Heizungssteuerung.

1-Wire ist da das richtige Stichwort! Da sollte ich mit den Kabellängen keine Schwierigkeiten bekommen...wobei ich die  Netzwerkleitungen Sternförmig verlegt habe...Ich denke der AM2301 DHT21 ist da ein geeigneter Kandidat. Der ist schon für 3,67€ bei Ali zu bekommen.
Ich habe auch noch ein bisschen weiter gegoogelt und den BME280 gefunden. Dazu habe ich auch ein Projekt gefunden, das Batteriebetrieben mit dem BME280 und einem ESP Daten übermittelt. https://hackaday.io/project/20588-espmobe-battery-powered-esp8266-iot-sensor
Sehr interessant, da die Batterielaufzeit bei einem Intervall von 10 Abfragen / Stunde ca. 1 Jahr beträgt.
Wäre nur wieder viel Aufwand mit Löten, Gehäuse basteln etc. Aber es macht ja auch Spaß.
Habt ihr weitere Vorschläge zu selbstbau-Projekten?

Noch interessanter finde ich den Perl Sensor (FWS790 NC-7159) für 5,90€ inkl. Display für die Vorort-Anzeige. Sendet auf 433MHz. https://www.pearl.de/a-NC7159-3041.shtml´
Auch dazu gibt es ein schönes Raspberry Projekt: http://www.w3raspi.de/c/raspberry-pi-funkwetterstation-433-mhz/
Hier wird der Sensor mit einem einfachen 433MHz Modul empfangen und mit Pilight verarbeitet. Ich konnte jetzt noch nicht herausfinden, ob es auch möglich wäre diesen direkt mit meinem 433MHz CUL (SlowRF Mode) zu empfangen. Alternativ müsste ich meinen Raspberry überreden mit Pilight zu Arbeiten. Aber irgendwas will da nicht. Ich habe auch noch ein älteres Wheezy laufen.
Ich weiß auch nicht, ob die Sensoren jeweils eigene IDs haben. Wäre sonst blöd.
Habt ihr vielleicht andere Vorschläge für fertige Sensoren?

JeeLink habe ich jetzt  bewusst nicht mehr verfolgt. Ist mir einfach zu teuer.

Schwieriges Thema...und alles nur, weil die MAX Thermostate nicht bzw. n ur selten die Temperatur übermitteln...

Gruß
Bismosa

1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Beta-User

MySensors?

Da kannst du im Prinzip auch alles als Sensor nutzen, wofür es eine Arduino-lib gibt...
Und Arduino+RFM69 sind deutlich stromsparender als ESP8266.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

Ob OneWire mit einem echten Busmaster über deine CAT6 und ob nur Temp (DS1820) oder mehr (BME280) ,
dazu gibt es haufenweise Freds , entweder im 1W Sub Forum oder in der Bastelecke. Die Bastelecke ist auch die erste Anlaufstelle zum Thema ESP8266 ( eigens Subforum ) auch hier gibt es mehr Lösungen als ich Finger an beiden Händen habe.

BTW : "Wer billig kauft , kauft min zweimal" oder auch  "Sonderangebot sind nur etwas für Reiche"
(denn wer wenig Geld muss sehen etwas Gescheites für sein Geld zu bekomme und nur reiche Leute können sich erlauben jeden Mist zu kaufen und bald darauf wegzuwerfen)

In diesem Sinne : Lass die Finger von den Pearl Dingern ! Ich hatte selbst mal drei die heute alle im "Elektrohimmel" sind,
a. taugen sie nicht viel und b. hat der Kanalwahlschalter nur drei Stellungen, d.h. ab Sensor 4 hast ein Problem. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Zitat von: Wzut am 25 Oktober 2017, 14:20:09
Ob OneWire mit einem echten Busmaster über deine CAT6 und ob nur Temp (DS1820) oder mehr (BME280) ,
Funktioniert der BME280 auch als 1-Wire-Device? Ich kenne bislang nur Ausführungen mit I2C- oder SPI-Bus. Und jedenfalls mit I2C sind dann die Anzahl der Devices pro Bus das Problem (max. 2), soweit mir bekannt. Oder nimmst du eine mcu als I2C<->1-wire-Umsetzer?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

bismosa

Hallo,
ich habe den BME280 auch nur als I2C gefunden. Ich hatte den auch nur genannt, da ich das Projekt mit dem ESP gefunden hatte.

Zitat von: Wzut am 25 Oktober 2017, 14:20:09
In diesem Sinne : Lass die Finger von den Pearl Dingern ! Ich hatte selbst mal drei die heute alle im "Elektrohimmel" sind,
a. taugen sie nicht viel und b. hat der Kanalwahlschalter nur drei Stellungen, d.h. ab Sensor 4 hast ein Problem. 
Danke. Ich hatte noch nicht gesehen, das es nur 3 Stellungen gibt.

RFM69? Das wäre doch auch wieder JeeLink? Da muss ich mich nochmal einlesen. Puh.

Das hatte ich mir einfacher vorgestellt...

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wzut

Sorry habe ich etwas unglücklich formuliert, der BMP280 bezog sich in dem Satz nicht auf 1W sondern auf die Bastelecke
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Zitat von: bismosa am 25 Oktober 2017, 14:53:55
RFM69? Das wäre doch auch wieder JeeLink?
Nein, man kann diesen Transceiver auch statt eines nRF24 (oder RS485-Bausteins) für MySensors verwenden, gibt sogar die Option, eine LoRa-Variante zu nutzen (RFM95).

Statt des Jeelink wird dann ein eigenes GW verwendet, zum prinzipiellen Einlesen: https://wiki.fhem.de/wiki/MySensors_Starter_Guide.

Etwas Programmierkenntnisse (oder den Willen, es zu lernen) sollte man aber mitbringen...

Zum BME280: Sketch für MySensors@RS485 ist hier zu finden (braucht aber eine etwas ältere Version der BME-lib, da hat jemand jüngst zu viel für den ESP8266-Einsatz optimiert).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

Zitat von: bismosa am 25 Oktober 2017, 14:53:55
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren

hmm , TX3 bzw. als  TFA 30.3121 ? Günstiger als der TX29 und den passenden Empfänger hast du schon
Wenn Google recht hat gibt es den bei ELV für 9,95€ als Art Nr 68-05 96 44
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

bismosa

Hallo,

danke für den Tipp! Ich denke der TFA 30.3121 ist die "günstigste" fertige Variante.
Ich habe auch noch weiter gegoogelt, gesucht und gelesen. Den hier finde ich auch nicht uninteressant:
https://forum.fhem.de/index.php/topic,52755.msg445543.html#msg445543
Das in ein kleines Gehäuse...und gut is. Müsste ich mich nochmal mit beschäftigen. Gerade was die Programmierung angeht...ich habe noch nicht viel dazu herausgefunden. Ich denke mal nicht, das es so mit meinem CUL Empfangbar wäre.
Ich würde diese Variante fast bevorzugen...dann kann man auch mal 2 oder 3 davon in ein Zimmer legen und kann die Temperatur beobachten. Das löten ist kein Thema für mich...solche Elektronikknäuel habe ich schon mehrfach erstellt.  :)
Wenn da nur der Faktor Zeit (für die Programmierung) nicht wäre. Das muss ich erstmal vertagen.

Ich habe den Max-Scanner nun leider erstmal wieder deaktivert. Ich hatte nun im Testbetrieb umgestellt auf "Mode Change". Es gab aber Beschwerden von meiner Familie, das neu eingestellte Temperaturen (am Heizkörperthermostat) sich kurze Zeit später wieder zurückgestellt haben. (Da wusste der Scanner wohl noch nichts von der Änderung und hat diese überschrieben...)

Vielen Dank für die ganzen Tipps!

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...