"Selbstbau" Ersatz für S300TH

Begonnen von atietzel, 03 März 2014, 12:13:05

Vorheriges Thema - Nächstes Thema

atietzel

Hallo zusammen,

ich habe erst mal gesucht, wo ich denn das, was ich gerade baue vorstellen kann. "Größeres Projekt" trifft es gleich in mehrere Hinsicht. Es wurde/wird nämlich aufwendiger, als ich zunächst glaubte und das, was damit zusammen mit FHEM realisiert werden soll, wird auch gleich von den Dimensionen etwas größer.

Es beginnt damit, dass ich vor etlichen Jahren mal damit begonnen habe mehrere FHT8v direkt mit dem CUL anzusteuern um eine Heizungsregelung selbst aufzubauen. Damals gab es die S300TH und S555TH, wie sie bei Conrad hießen, für sagenhafte 5€. Also habe ich damals gleich die maximale Anzahl gekauft, die überhaupt über einstellbare IDs gleichzeitig betreibbar sind.

Die damit realisierte Regelung funktionierte überzeugend gut. Bis heute läuft bei bei uns zuhause die Erstimplementation. Größere Probleme machte nur der WAF, der sich durch Verbesserungen in der Bedienbarkeit und ein paar Schmankerl, wie "vergessenes offenes Fenster erkennen" aber signifikant steigern ließ.
Die Batteriestandzeit der betreffenden Lösung ist sehr gut! Ich kann die Batterien mindestens zwei Jahre laufen lassen, eher sind es in Sensoren und Stellmotoren drei Jahre. Deshalb bin ich von der Bauart zumindest der Stellantriebe auch sehr überzeugt. Die Funktionsweise des nur kurz zum Empfangen Erwachens ist überzeugenden. Im Prinzip hat man es hier mit einem TDMA-System (Time Division Multiple Access) zutun. Die Übermittlung erfolgt in einem festgelegten Zeitschlitz. Daran halten sich nur die S300TH leider nicht.

Trotzdem hat die Installation ein paar Schwächen. Die S300TH senden, wann sie wollen im etwa drei Minuten Rhythmus. Dies führt dazu, dass die Regelung etwas "schwammig" aufgesetzt werden muss und dazu, dass sich manchmal die Aussendungen des CUL (Richtung der FHT8v Stellantrieb) mit den Aussendungen der S300TH überlagern. Letztlich ist das aber nur eine Schönheitsfehler und nichts, was tatsächlich die exakte Ausregelung der Temperatur signifikant beeinflussen würde. Aber man optimiert ja gerne...

Das viel größere Problem ist, dass mir neulich ein S300TH gestorben ist. Der Arme lag abgefallen in einer Pfütze, was die Schalter korrodieren ließ und somit die ID nicht mehr stimmte. Beim Versuch der Reparatur ist mir beim "Aufknacken" des verklebten Gehäuses das Quarz für den Sender leider abgebrochen und da wahren es nur noch n-1 Sensoren...

Also stellt sich nun langsam die Frage der Alternative. Wie ich sehe wurde die Diskussion auch schon hier im Forum begonnen.
Ich möchte auf eine kombinierte Temperatur- und Feuchteinformation pro Raum nicht mehr verzichten.
Zum Anderen wird sich wohl bald ein neues Problem auftun. Ein Freund (der Gefallen an meiner Installation gefunden hat) und ich selbst werden in naher Zukunft jeweils mit unseren Familien eine eigene Immobile beziehen. Er sogar eher, als ich. In dem Zusammenhang reichen die IDs der S300TH ohnehin nicht mehr aus und es werden vermutlich auch mindestens zwei Sender für die FHT8v und sonstiges "Spielzeug" benötigt um sowohl von der Funkabdeckung als auch vom Sendebudget (1%-Regel) keine Probleme zu bekommen.

Also habe ich mir einen CSM als Grundlage meiner Experimente für einen neuen, eigenen und leistungsfähigeren Temperatur/Feuchtesensors von dem besagten Freund mit bestellen lassen, als dieser für erste Experimente seinen CUL bestellte (den CUL habe ich jetzt auch für Experimente eingesackt, aber dazu später mehr).

Eine grundsätzliche Anfrage habe ich auch an Rudolf geschickt um zu erfahren, wie er als ,,Chef" des Projektes darüber denkt und wie er so etwas implementieren würde. Sein Vorschlag war, neben ein paar Anmerkungen, dass ich dies mal hier im Forum vorstelle. Das mach ich dann hiermit jetzt mal.

Ich habe jetzt schon ein paar Tage investiert und die Lösung läuft grundsätzlich. Es gibt jedoch noch etliches Optimierungspotential. Sowohl die Kosten als auch die Leistung des Sensors entsprechen noch (lange) nicht dem, was ich mir vorstelle.

Im angehängten Foto ist der Aufbau zu sehen. Ich habe einen CSM mit einem ISP-Stecker auf eine Platine gesetzt und die UART Schnittstelle des ATmegas über ein Sparkfun FT232-Modul verbunden (benutze ich gerne für solche Experimente, da kommen auch gleich, bis maximal 50mA belastbar, Spannung raus), damit ich Debug-Output und Kommandoschnittstelle habe. Dazu habe ich zunächst gleich am ersten Tag des Projektes sowohl einen SHT75 Sensor als auch einen DHT22 bestellt. Der SHT75 ist als erstes auf der Platine  gelandet, da er einfach schneller geliefert wurde. Den Grund, warum ich den DHT22 bestellt habe, kann sich wohl jeder sofort denken, wenn er auf die Preise schaut, die für einen SHT75 verlangt werden. Der Vergleich der Sensoren steht noch aus. Die Daten des SHT75 überzeugen mich allerdings schon.
Ansonsten sind auf der Platine noch zwei Jumper und zwei Buchsen zu sehen. Mit dem einen Jumper kann ich die Spannungsversorgung wählen, man kann die Versorgung über den FT232 setzen oder über den mySmartUSB light Programmer. Als dritte Steckoption kann man noch Batterien wählen, die sehr bald dazu kommen wird. Die Stecksockel für zwei Mignonzellen sind bereits besorgt. Der zweite Jumper dient dazu die Strommessung (High-Side) über ein DMM zu ermöglichen, dass ich extra für dieses Projekt für 13€ gekauft habe, damit es im/am Aufbau verbleiben kann. Es handelt sich um ein VC170 vom Grabbeltsich im Ausverkauf. Es ist beeindruckend was man für so kleines Geld bekommt. Das DMM wird über die zwei Bananenbuchsen angeschlossen und dann der Jumper (im Betrieb) gezogen. Einzige Verbesserung hier wäre ein parallel zum Jumper geschalteter Taster um die (leider) nötige Bereichsumschaltung am DMM von mA auf uA-Messbereich unterbrechungsfrei im Betrieb durchzuführen zu können.

Zunächst habe ich mir Folgendes gedacht um möglichst Problemlos funktional besseren Ersatz für die S300TH zu haben: Ich nutze die Aussendungen, die der CUL an die FHT8v schickt um mich auf das Zeitraster zum jeweiligen Stellantrieb zu synchronisieren und ermittle daraus eine Zeit für einen "Slot", die vor der Aussendung an die Stellantriebe liegt um dort synchron die Messwerte im Protokoll, die auch von den S300TH verwendet werden, zu senden.
Dazu habe ich zunächst die Telegramstruktur der S300TH verstanden und mir ein Programm gebastelt, mit dem ich auf der Kommandozeile die Telegramme über den CSM senden konnte. Das Ergebnis war ernüchternd. Sehr häufig gingen Telegramme verloren. Zunächst stelle ich noch fest, das die Firmware für den CSM den internen RC-Oszillator verwendet, der relevant daneben lag. Ich habe dann erst mal auf den extern, auf dem CSM vorhandenen Quarz umgeschlatet. Das brachte gefühlt etwas Verbesserung aber noch keinen Durchbruch. Zumindest war aber der fht8v_timeout-Zähler (um den es gleich noch geht) damit besser synchron zu dem im sendenden CUL. Die Empfangs und Sendeprobleme blieben aber bestehen und nur gefühlt weniger.
Trotzdem wollte ich erst einmal anfangen das Gesamtsystem zu implementieren. Um solche Probleme wollte (und will ich mich immer noch) später kümmern also beließ ich es erst mal damit, dass es gelegentlich funktionierte.
Ich habe mich zunächst einmal darauf gestürzt abzuschätzen, ob ich denn überhaupt einen Sensor hin bekomme, der vom Stromverbrauch akzeptabel wird. Und somit habe ich mir Soruce-Code zusammengesammelt, der den SHT75 bedienbar macht (ich wollte ja möglichst schnell fertig werden. Das hat sehr schnell,mit kleinen Änderungen geklappt). Es ist einfach toll, was Arduinos für ein Klima geschaffen haben, in dem Gebastelt wird, was das Zeug hält! An dem gefundenen Source-Code hat mich alleinig gestört, dass der Autor den bidirektionalen Open Collector Datenpin als Push/Pull benutzt hat. Das ließ sich durch wenige Zeilen ändern, indem ich das Datenbit des entsprechenden Pins einfach statisch auf 0 stellte und die Daten per DDR-Register ausgab. Das kommt einen Open-Collector gleich und der Pin ist automatisch als Eingang konfiguriert, wenn ich keine Null ausgebe. Die Kommunikation habe ich im Stile der restlichen CUL-Firmware nicht in einen Interrupt verlegt, sondern "zu Fuß" in der Hauptschleife gemacht, angetriggert durch den Synchronisierten fht8v_timeout- Zähler.

Im Übrigen habe ich ich den fht8v_timeout-Zähler gewählt, da sich damit mehrere CULs zukünftig synchronisieren lassen und so die Aussendungen an Stellmotore ebenfalls zeitlich zueinander (bei geschickter Wahl der Hauscodes) kontrollierbar sind. Dazu werden die Resetwerte bei erfolgter Erstsynchronisation nicht auf die maximale Periode (unter Einbeziehung des vier Bits aus dem Hauscode) gesetzt (wie das derzeit bei meinem Sensor der Fall ist), sondern so zueinander versetzt, dass im Endeffekt die einzelnen CULs (je nach Anzahl) um 180° bei zwei CULS bzw 120° (360° entsprechen der Sendewiederholperiode) bei drei CULS zueinander versetzt werden. Bei weiteren Nachsynchronisationen soll dann langsam nach gesteuert werden, indem bei einer Differenz in mehreren Schritten die lokale Aussendung verschoben wird um die FHT8vs ,,mitzunehmen". Im Moment steht noch ein Experiment aus, nämlich herauszufinden, wie schnell sich die FHT8v in ihrem Empfangszeitslot verschieben lassen. Der Aufbau dazu steht bei mir im Büro, damit es mir nicht zuhause "dazwischen funkt". Dazu werde ich die Firmware so erweitern, dass sie jeweils einen Offset bei jeder Aussendung an die FHT8v dazupackt und mir dann anzusehen, wie groß dieser maximal werden darf, bevor ich die Stellantriebe "verliere". Die synchronisierte Firmware kennt übrigens jetzt zwei Hauscodes, die sie auch im EEPROM speichert, das ist zum einen der Sende-Hauscode, den man mit dem Kommando T01 einstellt und daneben gibt es noch einen Hauscode, der bei mir das neue Kommando T12 bekommen hat, mit dem der Hauscode eingestellt wird, auf den sich aufsynchronisiert werden soll. Die beiden Hauscodes dürfen natürlich nur so zueinander variieren, dass sie kein unterschiedliches Aussendeinerval ergeben, das wäre (verständlicherweise) nicht synchron zu halten.

Bis hier funktioniert die Lösung übrigens gut, wenn man die Funkübetragungsprobleme außen vor lässt. Ich lege mittlerweile auch den CC1101 außerhalb seines Empfangs- und Sendefensters schlafen. Dazu benutze ich den Strobe PWD um auch den internen Spannungswandler des Bausteines auszuschalten. Bleibt alleinigs der ATmega. Um dort wirklich das Letzte an Strom sparen zu können müsste man ihm wohl einen externen 32,768kHz Quarz spendieren, wo im Moment noch ein 8MHz Quarz aufgelötet ist und die Application Notes von Atmel durcharbeiten, wie man 2% bis 1% genau den RC-Oszillator kalibriert. Das habe ich mir erst mal gespart und eine externe Lösung (in einer fluchdeden SMD-Lötsession) erarbeitet. Ich habe mir ein paar RV3029-RTCs besorgt, die es für unter vier Euro gibt. Und diese behelfsmäßig auf einen DIL-Sockel gelötet. Mit diesem Aufbau lässt sich fast zwei Minuten lang ein Stromverbrauch des Gesamtsystems von unter 10uA realisieren. Eigentlich müsste sich dies laut Datenblätter aller beteiligten Bausteine sogar noch einmal deutlich reduzieren lassen, nämlich rechnerisch im Bereich von unter 2uA. Aber selbst wenn ich noch nicht weiß, wo es herkommt, dass manchmal 10 bis 13uA und manchmal nur 8uA fließen, das Ergebnis ist schon mal gut.  Es gibt da noch einige Merkwürigkeiten:
Der CC1101 wacht nur richtig wieder auf, wenn ich im zwei mal hinter einander mit set_ccon wecke. Und manchmal komme ich nicht unter 700uA. Da habe ich aber schon gefunden, dass es dann passiert, wenn der SHT75 seit Power On noch nicht gelesen wurde. Ist dies ein Mal passiert, sinkt der Stromverbrauch in der Schlaftphase des Systems deutlich.

Rein rechnerisch komme ich in etwa auf 100 Tage Batterielebensdauer, wenn ich in jedem Intervall die volle Show mache, indem ich sende und synchronisiere. Das Synchronisieren lässt sich sicher deutlich seltener machen, ich hoffe eher im Stundenbereich, indem ich die Zeitfenster/Zeitschlitze für die Aussendungen einfach etwas weiter fasse, so dass sich leichte Abweichungen in den synchronisierten Zählern (im höchsten Stromsparmodus im Moment im RV3029) nicht gleich zu Sendeüberlappungen führen. Das Sensor Auslesen und Senden geht natürlich nicht seltener. Also ist darauf zu achten, dass dies möglichst effektiv geschieht.

Es verdichtet sich immer stärker die Erkenntnis, dass es geschickt sein wird den CC1101 intensiver zu nutzen.
Ich kann nicht abschätzen, wie viel sich noch aus Optimierung des SlowRF-Codes herausholen lässt um noch höhere zeitliche Exaktheit bei der Auswertung des Empfangssignals und der Generierung des Sendesignals herzustellen. Wenn sowohl Sender und auch Empfänger die Implementation basierend auf der CULFW nutzen sieht dies (ohne genaue Messungen gemacht zu haben) nicht optimal aus.
Eine kleine Verbesserung habe ich allerdings eingebaut, ich habe den 125Hz Timer einfach mal doppelt so lange laufen lassen. Davon erhoffte ich mir auch weniger Stromverbrauch und weniger Jitter. Es funktioniert aber ich habe keine exakte Auswertung des Ergebnisses. Beim Stromsparen ist die Sache eindeutig, nur das Verwenden von Stromspartechniken, wie Idle und Power Down bringen echte Verbesserungen.
Aber zurück zum Funk: Meine Idee bisher ist, dass der CUL, der auch an eine Gruppe von FHT8v die Stellinformationen schickt, eine zusätzliche Barke unter Ausnutzung seiner Fähigkeiten (FastRF) schickt (sozusagen ein TDMA). Dazu würde ich eine Anregung von Rudolf berücksichtigen und durch eine Präambel, die er beim RF-Router auch so verwendet hat, einem lauschenden anderen Device die Möglichkeit geben ebenfalls zum Empfang der Barke in den FastRF-Mode zu wechseln. Diese Barke sollte einen Zeitschlitz vor denen für die Sensoren sein. Möglicher asynchroner Empfang von FS20 Sendern (ich habe so einen Handsender) während dieser Phase im SlowRF-Mode muss man prüfen. Das könnte sich vielleicht damit realisieren lassen den CUL immer, wenn er im Zeitschlitz eine Sensorinformation gefunden hat, diesen zurück in den SlowRF-Mode zu versetzen, bis der nächste Zeitschlitz für den nächsten Sensor beginnt (hier würde ich gerne aus Energieeffizizenzgründen auf eine Slow-RF-Präambel verzichten wollen, der CUL weiß ja wann die Sendung kommen müsste). Wie auch immer. Die Sensoren sollten dann ihre Information möglichst auch und nur in FastRF-Senden. Das wird vermutlich die Empfangssituation verbessern aber auch die Effektivität erhöhen, mit dem die Batteriekapazität der Sensormodule genutzt wird. Daneben löst sich auch das Problem mit der Begrenztheit der IDs bei den S300TH. Diese ließen sich dann sogar noch parallel zu den neuen Sensoren weiter betreiben (wenn man mag). Durch das Zeitschlitzverfahren wäre es aber ohnehin eindeutig, welcher Sensor gerade gesendet hat.

Am Ende des Projektes stünde dann noch eine BCP-Pool gefertigte Leiterplatte auf der alles (Microcontroller, Funkchip, Sensorchip und vielleicht RTC/Timer) hübsch angeordnet werden plus irgend eine Form von nicht all zu hässlichem Gehäuse. Eine offene Frage ist zum Beispiel, wie günstig man den SHT75 bekommt, wenn man nur genug Leute zusammen bekommt, die auch einen so schön und hoch genauen Temperatur/Freuchte-Sensor haben wollen. Die alternative Bestückung mit DHT22 wollte ich allerdings grundsätzlich offen lassen. Ebenso, für diejenigen, die Feuchte vielleicht nicht ganz so spannend finden, eine Lösung mit einem genau genug arbeitenden Temperatursensor. Zudem auch noch die Auslegung als Baufeuchtemessgerät mit zwei externen Elektroden und die Möglichkeit ein externes Netzteil anzuhängen um einen/ein paar der Module, die Raumsensor spielen sollen auch als RF-Repeater für FHT8v (und Weiteres) nutzen zu können, die dann im oben beschriebenen Verfahren synchronisiert sind zum ,,Haupt-CUL".

Anmerkungen und Ideen willkommen!

Mit freundlichem Gruß
Alexander

Dirk

Hallo atietzel,

Schönes Projekt.

ZitatEs verdichtet sich immer stärker die Erkenntnis, dass es geschickt sein wird den CC1101 intensiver zu nutzen.
In einem Parallelthread entwickeln wir grade so einen Sensor auf CC1101-Basis.
Vielleicht währ das was für dich.
http://forum.fhem.de/index.php/topic,20620.0.html

Was darauf dann für eine Software läuft ist dann ja zweitrangig. Da kannst du mit entsprechenden Anpassungen auch deine Software drauf laufen lassen.

Viele Grüße
Dirk

atietzel

ok, dass habe ich mir jetzt mal angesehen. Mir würde allerdings zur Erfüllung der zeitlichen Anforderungen noch etwas fehlen: Entweder den angesprochenen 32,768kHz Quarz oder eben den RTC/Timer Chip... Mit dem RV3029 bekomme ich nämlich im Moment recht ordentliche Synchronisationen hin. Zumal ich dann auch tatsächlich nur alle zwei Minuten den Microcontroller aus dem Power-Down wecken muss. Der RV3029 ist zudem temperaturkompensiert (wie gut das funktioniert, weiß ich noch nicht) aber das fand ich auch ganz angenehm...
Ansonsten ist das, was ihr da macht ja schon mal recht nett!
Ich werde aber erst mal auf meiner Hardware weiter machen (müssen) da ich einen fast vollständigen CUL mit in der Implementation habe um damit ein "Range Extender" zu realisieren. der ATmega1284p hat ja 16kByte RAM und 128kByte Flash. Das ist eine etwas andere Hausnummer. Insofern müsste ich erst mal beginnen das Ganze wieder herunter zu dampfen, so dass es in einen 32kByte Flash passt und weniger RAM benötigt, wo ich mir allerdings nicht sicher bin, ob das klappt. Anders herum wäre ein Kompromiss für den "einfachen" Sensor eure Schaltung/Platine zu nehmen und nur für den "Range Extender" einen größeren Microcontroller zu spendieren. Nach den Kosten habe ich noch gar nicht gesehen. Meine Hoffnung war, dass durch mehrere Leute der SHT75 und der ATmega1284p (und möglicherweise RV3029 oder ein anderer Temperaturkompensierter Timer AB-RTCMK-32.768KHz-T) günstig wird...

Dirk

ZitatEntweder den angesprochenen 32,768kHz Quarz oder eben den RTC/Timer Chip... Mit dem RV3029 bekomme ich nämlich im Moment recht ordentliche Synchronisationen hin.
In deinem Schlussabsatz sprichst du von "Temperatur/Freuchte-Sensor" Da sehe ich aktuell keine Erfordernis für eine so exakte Zeitsteuerung dass man eine RTC oder einen Uhrenquarz bräuchte. Du sagst ja auch, dass du eigentlich "nur" einen S300TH / S555TH ersetzen möchtest.

Anderseits sprichst du auch von Synchronisation mit den Stellantrieben. So richtig habe ich noch nicht verstanden ob das denn nun nur ein Sensor sein soll, oder ob du mit dem Sensor auch deine Antriebe steuern willst.

Wo willst du denn deine Daten messen, dass der Sensor eine so hohe Genauigkeit haben soll? Der SHT10 hat nur eine etwas niedriger Genauigkeit und ist im Gegensatz zum SHT75 um den Faktor 5 günstiger.

Vermutlich habe ich aber dein geplantes Einsatzszenario noch nicht ganz verstanden.

Gruß
Dirk

atietzel

#4
Hallo Dirk,

da habe ich mich wohl in meiner anfänglichen Beschreibung unklar ausgedrückt. Ich war (einer) der Erste(n), der eine Regelung mit FHEM direkt mit den FHT8v Stellantriebe aufgebaut hat. Dazu habe ich damals mit der culfw experimentiert und die heutige Ansteuerung entwickelt und einen (PID) Regler in Perl geschustert.
Rudi hat das Ganze dann ordentlich gemacht (vor allem den Perl-Teil).
Zur Erfassung der Temperatur hatte ich die asynchron laufenden S300TH verwendet. Die Feuchte war nett, da man damit versuchen kann den Taupunkt zu ermitteln und aufzupassen, dass man in der Wohnung keine schädliche Kondensation bekommt (Lüften, bevor es zu feucht ist).
Was ich nun mache, ist die Temperatur/Feuchte Information synchron zu den Aussendungen an die FHT8v zu senden.
Das verhindert die Probleme, die man mit den asynchron sendenden S300TH hat: sie senden, wenn gerade die Stellantriebsinformationen kommen oder wenn ein anderer Sender gerade aktiv ist. Außerdem ist die Tempeaturinformation zukünftig synchronen mit der Regelung (im FHEM) und den Stellantrieben.
Dazu synchronisiere ich derzeit den CUL auf die Aussendungen für die Stellantriebe. Die Regelung macht weiterhin FHEM und das soll auch so bleiben. Nur ist eine größere Installation geplant. Die in dem neuen Haus eines Freundes wird mehr als acht FHT8v haben und folglich auch mehr als die derzeit möglichen S300TH enthalten müssen. Dazu soll (mindestens) einer der Temperatur/Feuchte Sensoren zusätzlich die Aufgabe eines Repeaters übernehmen und dann nicht per Batterie, sondern per Steckernetzteil versorgt werden. Die zeitlich akkurate Synchronisation der Sensoren benutze ich, damit ich ohne aufwendiges Protokoll genau festlegen kann, wann die Aussendungen von den einzelnen Sensoren kommen sollen, jeder zugeordnet zu einem Stellantrieb in einem Raum. Außerdem. Außerdem will ich die Aussendungen an die Stellantriebe zueinander sauber separieren.

Macht es das klarer, worum es geht?

Gruß
Alexander

Dirk

Hi Alexander,

ZitatMacht es das klarer, worum es geht?
Ich versuche es mal:

Du möchtest die Telegramme der Sensoren zeitlich kurz vor dem kommenden Empfangsslot des entsprechenden Stellantriebes empfangen, damit du dem Antrieb quasi ohne große Verzögerung die neuen Werte übermitteln kannst?

Gruß
Dirk

atietzel


betateilchen

Deine Anforderung solltest Du eigentlich mit dem inzwischen weiterentwickelten PID20 Modul weitgehend abdecken können.
Dort kannst Du sehr viele Parameter einstellen, die Sendeintervalle an die Aktoren sind z.B. nicht mehr fest vorgegeben.

http://forum.fhem.de/index.php/topic,17067.0.html
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dirk

Kann man machen. Für meine Begriffe etwas "oversized" aber die Anforderungen sind ja verschieden.
Der Urenquarz sollte da aber trotzdem ausreichend genau sein. Die FHT8b haben auch keine RTC an Bord.

Zumindest währ in dem anderen Tread ja schon mal eine Idee für ein nettes und relativ günstiges Gehäuse.

Zitat von: betateilchen am 03 März 2014, 17:05:57
Deine Anforderung solltest Du eigentlich mit dem inzwischen weiterentwickelten PID20 Modul weitgehend abdecken können.
Dann nicht, denn die Sensoren müssen sich für seine Anwendung auf die Stellantriebe synchronisieren können. Das hat mit dem Algorithmus der die Regelung macht dann erst mal nix zu tun.

Gruß
Dirk

betateilchen

#9
Du kannst aber nicht auf die FHT8V Stellantriebe synchronsisieren, weil die (als reine Empfänger!) nicht in einem festgelegten Zeitabstand "hörbereit" sind, sondern dieses Zeitintervall variiert.

Die FHT8v hören im Normalbetrieb ca. alle zwei Min. ((125*(230+(fht_hc1&0x7)))>>1) auf Stellbefehle.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

atietzel

Die Werte in den Aussendungen an die FHT8v kann man vielleicht in vielfachen der Intervalle updaten, damit die Stellantriebe synchron mit dem Sendenden CUL bleiben muss man aber weiterhin in jedem Intervall senden (dann wird halt der alte Wert genommen). Das verbessert vielleicht, dass die Stellantriebe nicht zu flatterig hin und her fahren und Batterie verbrauchen. Das mache ich übrigens schon in meinem alten Regelmodul, indem ich noch mal einen Tiefpass hinter der Stellgröße habe. Damit habe ich schon ziemlich lange Batteriesandzeiten ich habe die alten Batterien nur letztes Jahr vorsorglich gewechselt, da wir mehrere Tage nicht zu hause waren und es kalt war, sonst hätte ich es mal drauf ankommen lassen zu sehen, wie lange die Batterien in den FHT8v eigentlich halten.

Ich habe mir die Weiterentwicklung des PID Modules noch nicht all zu genau angesehen aber diese grundsätzliche Bedingung muss bleiben. Ich kenne ja nicht das Innenleben der Stellantriebe aber auch bei meiner Synchronisation stelle ich sofort den Empfänger ab, wenn ich empfangen habe, was ich empfangen wollte. Da ich vermute, dass die FHT8v das genau so machen, habe ich damals vorgeschlagen nicht die Stellantriebsnummer (pro Raum) zur Differenzierung in der Aussendung zu verwenden, sondern jeweils einen eigenen Hauscode, der aber eine gleichlanges Intervall ergibt.
Ich weiß aber nicht, was mir das helfen soll, damit ich das Problem der nicht mehr verfügbaren S300TH umgehen soll. Und warum soll man das System nicht verbessern? Die synchrone Aussendung (die synchrone Verfügbarkeit von aktuellen Sollwerten) ist ein Beitrag zu Verbesserung der Regelbarkeit.

atietzel

#11
Zitat von: Dirk am 03 März 2014, 17:10:01
Kann man machen. Für meine Begriffe etwas "oversized" aber die Anforderungen sind ja verschieden.
Der Urenquarz sollte da aber trotzdem ausreichend genau sein. Die FHT8b haben auch keine RTC an Bord.

Das ist richtig. Aber die FHT8b brauchen sich auch nicht in einen Zeitschlitz synchronisieren. Je ungenauer meine Uhr ist, desto größer muss ich den Zeitschlitz für die einzelen Sensoren machen. Damit würde aber die Gefahr wieder größer werden, dass der CUL, der zu dem Zeitpunkt zukünftig im FastRF-Mode sein soll Aussendungen von anderen Funkkomponenten nicht mitbekommt. Deshalb soll das Ziel erst mal sein die Zeitschlitze so klein wie möglich und die Aussendungen so dicht aufeinanderfolgend wie möglich machen und die zu erwartende Drift so gering wie möglich zu halten. Die FHT8b und die FHT80b machen das ganz anders. Sie sind zueinander nicht synchronisiert und dürften sich von Zeit zu Zeit auch kurz gegenseitig stören. Genau aus dem Grund, damit diese Störintervalle möglichst kurz sind, hat der Hersteller wohl die Zeitintervalle für die Updates an die Stellantriebe leicht mit dem Hauscode variabel gemacht.

Nachtrag:
aber ich halte es auch für möglich, dass der Uhrenquartz reichen könnte. Aber da ein Teil der Sensoren, bei mir zwei im Außenbereich sein werden, rechne ich eben schon mit höherer Temperaturdifferenzen und hatte deshalb nach einer Temperaturkompensation gesucht um es einfach zu halten. Außerdem ist die Schlafdauer, die ich bei geringstem Stromverbrauch derzeit mit dem RV3029 erreiche, mit den internen 8-Bit Countern des ATmegas nicht erreichbar. Das ist eher aber auch nicht das KO-Kriterium. Es ist nur nett, dass es geht. Bisher ist allerdings noch gegen den RC-Oszillator sprechend, dass die SlowRF noch nicht sauber zwischen zwei Devices mit culfw läuft. Wenn ich längere resynchronisationsitervalle erreichen möchte, die eher im Stundenbereich liegen sollen, dann ist die Temperaturdrift aber vielleicht doch ein Thema. Dazu muss man aber erst mal Erfahrungen sammeln. Wenn man aber dieses Jahr Sensoren einbauen will, dann macht es das vielleicht etwas sehr unangenehm, wenn man erst nach der Installation feststellt, dass der ganze Zauber so stark driftet, dass es nicht mehr sauber läuft. Das kann man erst mal mit einer definierten Drift, mit der man rechnen kann, beherrschbar.

Ach so, noch ein Nachtrag zum SHT75:

den habe ich gekauft, da ich erst mal den besten vergübaren Sensor haben wollte, den man bekommen kann. Gegen den will ich z.B. den DHT22 noch vergleichen. Allerdings hat sich die Güte des SHT75 auch schon gezeigt. Es ist beeindrucken mit anzusehen, als ich den Sensor zwei Wochen im Büro habe laufen lassen, dass man sehr gut sehen konnte, wie sich die Feuchte der Luft über die Woche verändert und wie reporduzierbar das ist. Deshalb hätte ich schon ganz gerne das Ding. Aber aus kostengründen ist das eigentlich nur ein Wunsch, ich werde sehen. Immerhin will ich mit dem Ding regeln, deshalb ist die Güte des Sensors schon interessant. Die gute Feuchteinformation ist nur "nice to have". Allerdings habe ich schon bei der Durchsicht der Datenblätter gesehen, das die SHTs alle den Vorteil haben, dass sie besser als andere Sensoren mit Bedingungen rund um Betauung umgehen können (Bad, Küche und  Draußen) und ihre Lanzeitdrift auch sehr gut ist im Vergleich zu den anderen Sensoren. Es gibt noch einiges, was herausgefunden werden muss. Aber bei der Auslegung einer Lösung, die möglichst bald fertig sein soll gebe ich (wie ich das auch beruflich mache) gerne in der ersten Generation immer an allen Ecken etwas Sicherheit dazu. Wenn der Sensor nur allgemein ein bisschen vor sich  messen sollten und ich nur die Außentemperatur und Feuchte mitloggen wollen würde, dann wäre mir 5% noch genug. Wieviel ich für ein gutes Wohnraumklima brauche, will ich herausfinden. Ich werde definitiv nicht 10 SHT75 zum Preis von 30€ kaufen wollen...

Gruß
Alexander

stgeran

Preis für SHT75 ab 10 Stück ca. 23,50€ habe ich gefunden. Sind ab Lager lieferbar.
FHEM auf Raspberry
CSM 866MHz für EM1010 mit Strom und Gaszähler
CUL 866MHz für MAX! Radiator Thermostat 
CUL 433MHz für Innen und Aussen Temp
HMLAN für HM-LC-Sw1-PI-2