Verschiedenes > Projekte

"Selbstbau" Ersatz für S300TH

<< < (3/3)

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:

--- 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.


--- Ende Zitat ---
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.

Navigation

[0] Themen-Index

[*] Vorherige Sete

Zur normalen Ansicht wechseln