Aufbau eines neuen Systems

Begonnen von ritchie, 26 März 2013, 12:52:49

Vorheriges Thema - Nächstes Thema

ritchie

Hallo Zusammen,

ich bin neu in Sachen FHEM und bin derzeit meine Wohnungssteuerung am konfigurieren.

Als Basis-Station habe ich einen Raspberry PI Modell B und das Zusatzmodul Rasperry Pi - COC Erweiterung mit Antenne 15cm / Uhr / OneWire) am Start.

Da ich mit der Steuerung der Heizkörper anfangen will, hier meine Frage:

Kann ich die folgenden Komponenten ohne Problem an der FHEM in Betrieb nehmen

  - MAX! Heizkörperthermostat+
  - MAX! Fensterkontakt
  - MAX! Wandthermostat+

oder ist HomeMatic besser ?
Ich wollte eigentlich Komponenten mit Rückmeldung nehmen, also kein FS20.

Ich dachte hierbei eine solche Konfiguration für jeden Raum vorzunehmen (ausser Basis Station :-) ) und folgende Funktionen zu implementieren.

- Temperatur wird von FHEM (Basis Station vorgegeben)
  Temperatur nach Zeitprofil und durch Eingriff von Bediener regeln.
  Wandthermostat soll hierbei als zu regelnde Größe verwendet werden.
  (Kann man Thermostat und Wandthermostat kombinieren ?)

- Vorgaben von FHEM sollen am Thermostat und an dem Wandthermostat angezeigt werden.
   
- Temperatur soll via Wandthermostat für den aktuellen Tag geändert werden können,
  soll dann aber wieder für den folgenden Tag durch die Grundeinstellungen von FHEM
  wieder übernommen werden

- Fenster Kontakt unterbindet Heizfunktion


Kann man eigentlich auf dem Funkmodul mehrere Protokolle gleichzeitig fahren,
um unterschiedliche Hersteller zu kombinieren ?

Viele Grüße

R.
IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

Bene

Hallo Ritchie,

du sprichst mir aus der Seele. Ziemlich genau diese Ideen habe ich auch im Kopf. Auch exakt mit dem COC von busware.

Ich hatte mir überlegt, das ganze mit HomeMatic zu machen - das scheint ein gutes, modulares recht potentes System zu sein.

Bisher schreckt mich noch ab, dass die HM-Heizungssteller nicht direkt am Ventil stellbar sind - da wäre das Max!-System sinniger. Andererseits geht es ja um Automatisierung... Wieder andererseits scheit das Max!-System auch nicht z.B. die IST-Temperatur zu funken, sodass das COC, respektive FHEM überhaupt nicht erfährt, ob die Steuerung der Stellantriebe irgendeinen Erfolg hatte. Ich bin unschlüssig.

Um erste Erfahrungen mit dem COC und FHEM zu sammeln, habe ich mir ein paar DS18B20 bestellt. Dann kann ich schon mal lernen, Geräte in FHEM erkennen zu lassen und immerhin schon die Temperatur auslesen. Man muss ja klein anfangen. :-D

Hast du schon weitere Erkenntnisse?

Viele Grüße

Bene

ritchie

Hallo Bene,

ich habe derzeit meine Hardware installiert und muss derzeit die COC auf den neusten Stand bringen.
Ohne dies, arbeitet der COC nicht korrekt mit MAX! zusammen.

Gruss R.
IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

Bene

Hi Ritchie,

definiere doch mal kurz "auf den neuesten Stand bringen"...
Ich habe die COC.hex geflasht, die man HIER bekommt. Das flashen war erfolgreich und der Hexdump-Output okay.

Da ich aber noch keine Sensoren/Aktoren habe (die DS18B20 sind im unterwegs...), kann ich halt noch nicht testen, ob es wirklich funktioniert...
Funk-Aktoren kommen, wenn es monetär drin ist.

Bene

ritchie

Hallo Bene,

ich habe hier wohl die COC mit der CUL verwechselt.

Ich habe die gleiche Version von
http://culfw.svn.sourceforge.net/viewvc/culfw/trunk/culfw/Devices/COC/
geladen. Danach hat mein Anlernen korrekt gearbeitet.

Die Sensoren "DS18B20" werde ich mir später zulegen, wenn mein Keller dran ist.
Hier werde ich ein AVR-NET IO Board installieren und via Ethernet & Ethersex
die Kommunikation mit FHEM aufbauen.

Gruss R.
IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

thn1966

Hallo ihr zwei,

nur mal zu eurer Information: FHT arbeitet auch mit Rückkanal, nur FS20 nicht.

Für welches System ihr euch entscheidet, hängt davon ab, was ihr noch vor habt. Bei Max! gibt es (bis jetzt) nur die Heizungskomponenten, HM ist das teuerste von den drei, bei FHT/FS20 gibt es derzeit die größte Auswahl. Und freundlicherweise fahren alle drei ihr eigenes Protokoll. Man legt sich also fest...

Ihr solltet also noch mal bei den einschlägigen Anbietern schauen, was es so gibt. Nach meinen Erfahrungen ist ein Rückkanal oft nicht nötig, HM soll aber die besseren Empfänger haben und damit bei schlechten HF-Bedingungen zuverlässiger sein. Da ich bisher nur ein Gerät mit Bidcos habe, kann ich mich nicht wirklich dazu äußern. FS20 ist z.B. gut, wenn ihr eigene Lösungen basteln wollte, da es hier auch einige halbfertige Komponenten gibt.

Einen schönen Sonntag
ThN

Dirk

Der "Rückkanal" bei HM funktioniert aber deutlich zuverlässiger als der vom FHT.
Zusätzlich sind viele FS20 Komponenten (noch) nicht LTE-Störfest.

Und ein "Rückkanal" bzw. eine Bestätigung ist immer dann Sinnvoll, wenn man den Status eines Aktors genau wissen möchte.
Vor allem Bei Toggle-Befehlen (also an/aus) kann es passieren dass bei FS20 zwar der Aktor schaltet, FHEM das aber z.B. durch eine Störung davon nix mitbekommt. Dann ist das Gerät für FHEM z.B. noch aus, in Wirklichkeit aber an.
Bei HM kann man den Status vom Gerät, zumindest bei Aktoren mit Netzversorgung, direkt per Befehl anfordern.

Daher ist es eine Überlegung Wert bei einer Neuanschaffung genau zu überlegen ob HM, oder ob FS20.

Gruß
Dirk

thn1966

Hi,

Toggle nutze ich nicht, da ich in einigen Fällen mehrere Aktoren über einen Befehl schalte. Und da kann ein nicht empfangener Befehl tödlich werden. Mit LTE habe ich bisher keine (bewußte) schlechte Erfahrung gemacht. Ich habe FHT und FS20 schon zu Zeiten betrieben, als LTE mit seinen Problemen noch kein Thema war. Unterdessen gibt es bei uns LTE und wie im ländlichen Raum üblich um 860Mhz. Einige Nachbarn nutzen es auch, wie intensiv weiß ich nicht. Eine Verschlechterung habe ich bisher nicht feststellen können, meine Problemfälle sind geblieben und neue nur durch neue Komponenten entstanden.

Trotzdem werde ich beim weiteren Ausbau vorzugsweise HM einsetzen. Grund ist die 1%-Regel. Slowrf ist bei mir durch 8 FHTs mit mehreren Stellantrieben und Fensterkontakten schon ganz gut belegt. Und es muß ja nicht erst Probleme geben.

Gruß
ThN

thn1966

Ach ja, was ich noch einwerfen wollte: Rückkanal ist bei HM relativ. Ein echter Rückkanal würde den Vollzug melden, HM (und alle anderen auch) meldet aber nur den erfolgreichen Empfang. Einen wirklichen Rückkanal muß man bei Notwendigkeit separat aufbauen.

ThN

Dirk

Der "Rückkanal", also die Bestätigung von HM wird gesendet wenn der Aktor den entsprechenden Befehl ausführt.
In sofern ist das schon eine echte Rückmeldung. Ob aber nun das ausführende Relais, oder der Rolladen klemmt kann natürlich nicht dadurch erkannt werden. Dazu bedarf es dann eines zusätzlichen Sensors.

Ein Dimmer z.B. erkennt aber ob die Lampe an oder aus ist. Stichwort Lastfehler.

Gruß
Dirk

Rohan

Zitat von: Dirk schrieb am Mo, 08 April 2013 17:55... In sofern ist das schon eine echte Rückmeldung.

Vor allem bei HM-CC-TC mit den VDs hast du entsprechenden Meldungen, ob die VDs auch die angewiesene Stellung eingenommen haben (Stichwort: TargetNotMet bzw. OnTarget). Das ist mehr an Rückmeldung als du anderswo erwarten kannst.

Ansonsten: Was nutzt dir die Rückmeldung, dass ein Lichtschalter weisungsgemäß eingeschaltet hat, kurz vorher aber das Leuchtmittel durchgebrannt ist. Hier würde eine *echte* Rückmeldung so aussehen, dass du einen zusätzlichen Helligkeitssensor am Aufstellort der Lampe hast, der dir rückmeldet, dass die Lampe auch leuchtet ;)

Wieviel an Rückmeldung jemand braucht, liegt im Auge des Betrachters und ist auch eine Frage zwischen Daumen und Zeigefinger.

Gruß
Thomas
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor