Beiträge von borsti0

    Jep, der Humidity-Sensor arbeitet auch kapazitiv und kann natürlich auch nicht zaubern. Er hat auch das "typische" Satzerl drinnen, obwohl mich die +3% ned schrecken.:
    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Aber der besitzt KEINE Heizung, dafür steht auf der Ruuvi-Homepage die Einschränkung "non-condensing only!" bis max. 95% relative Humidity.

    D.h.: wenn der Sensor mal GESCHEIT feucht wird, dann wird er mal ein zeitl ned funktionieren bis das Wasser wieder von alleine verdunstet => da würde eben dann die Heizung helfen.

    Ich hab zwar keinerlei Feuchtesensoren (von Shelly) in Betrieb, aber ich hab mir mal 2/3 diskrete Humidity-Sensorchips kurz mal angeschaut. Die funktionierten ALLE mit einer Art "feuchteanziehenden Dialektrikum". Wenn sie dann die Kapazität dieses Dialektrikums messen können sie auf die Feuchtigkeit zurückschließen.
    Das "Komische" dabei: die hatten ALLE eine Heizung direkt im Chip integriert um nach einer hohen Feuchtigkeit diese wieder "rauszuheizen" um eine neue echte Messung zu ermöglichen. Diese Heizung brauchte dabei >100mW für eine gewisse Zeit (>50ms).

    Ich vermute mal dass diese Heizung bei den Batteriebetriebenen Shelly-Produkten nicht aktiviert wird.

    allgemeine Infos falls du nicht eh schon gemacht hast:
    a) Du musst den Shelly 2PM Gen4 in den "Cover"-Modus umschalten, per Default ist der im "Switch"-Modus. Nur so kannst du die "Cover"-Funktionen nutzen, ansonsten bleibt es quasi ein "2-Fach-Schalter" für z.b.: 2 Lampen.
    b) Du musst (oder solltest zumindest) deine Raffstore/Rollo KALIBRIEREN, ansonsten kannst du das Raffstore nicht an eine spezifische Position schicken (z.b.: "fahre auf 70% offen")
    c) Da du Raffstore hast kannst du die "slat control" einschalten. Da musst du dann die Zeiten zum kompletten öffnen/schließen der Lamellen bestmöglich händisch einstellen.

    Du hast bei den Eingangs-Tastern grundsätzlich folgende "Events" zur Verfügung die verarbeitet werden können:
    - short push
    - long push
    - double push
    - tripple push

    OHNE "slat control" hast du per default folgendes Verhalten:
    - short push Drücken der Up/Down-Taste: Raffstore fährt rauf/runter bis Endposition
    => Bei erneutem Drücken einer Taste wird die Fahrt gestoppt

    MIT "slat control" hast du per default folgendes VERÄNDERTES Verhalten:
    - short push Drücken der Up/Down-Taste: Lamellenwinkel verstellt sich um 20% Richtung "offen" bzw. "geschlossen" (die % können konfiguriert werden)
    - long push Drücken der Up/Down-Taste: Raffstore fährt rauf/runter bis Endposition
    => Bei erneutem Drücken einer Taste wird die Fahrt gestoppt

    Dieses Verhalten kannst du noch mit "Actions" oder Scripte lokal erweitern, oder mittels überlagerter Hausautomatisierung zumindest Hausintern erweitern
    z.b.:
    - double push => fahre alle notwendigen Raffstore nach oben/unten (=> das habe ich bei mir über Home Assistant so "erweitert")

    Wenn dir das Default-Verhalten nicht gefällt musst du die Eingänge auf "detached" stellen und ALLE Aktionen händisch nachbauen:
    z.b.:
    - short push => fahre nach oben/unten
    - long push => kippe Lamellen um X% rauf/runter
    - double push => fahre alle notwendigen Raffstore nach oben/unten (=> das habe ich über Home Assistant so verwendet)
    - tripple push => ???

    I use the Waveshare RS485 to RJ45 Ethernet Converter Module (~38€) as PoE-variant. There is basically no firmware support, software support and documentation from the manufacturer, but I was able to integrate it with Home Assistant anyway.
    For "configuration" you must use the web interface or the software "Virtual Serial & Device Management" alias "VirCom".

    Because I did not have ANY experience with Modbus and after several failed tests I also bought the Waveshare Industrial USB to RS485 Converter with original FT232RL 300-921600bps (~18€) to test to communicate from 1 device to the other using a Modbus slave and master software.

    I used a combination of "qModMaster" and "Modbus Slave" to try out several modes, parameters, register datatypes, ...
    After successful tests I also used the "Modbus Slave" software to try to access the registers of the simulated device with HA.
    => Only after these first tests I connected the RJ45 Modbus adapter to my MVHR.

    My parameters of the Waveshare RS485 to RJ45 Ethernet Converter Module as "Gateway":
    Attention: I increased the Baud Rate to 115200 baud => this parameter I had to change via my MVHR terminal, default was 9600 baud.
    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Initially I mapped each register by hand in the yaml file, example with only 1x "binary_sensors":
    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    But I was lucky and found a Modbus integration directly for my MVHR-device and could remove these lines (and several more) - you have to read the Modbus help for HA to understand these and MUCH more available parameters.

    Hier mal als Vergleich der Verlauf bei der alten und neuen Maschine (bei der alten ist ein 40 und ein 60 Grad Waschgang mit drauf.

    Der rechte breite Heizbereich bei der alten Maschine ging fast genau 30 min, der bei der neuen Maschine deutlich über eine Stunde.

    Aber wenn du sagst, bei dir sind es auch über 2 kWh dann liege ich vermutlich falsch.


    OK, bin nochmals durch die Logs gegangen: da wir meist nur 40°C "Pflegeleicht" und 60°C für die "schwierigen" Sachen waschen vermute ich dass man hier diesen Unterschied bei meiner Maschine sieht: Hier har der Energieverbrauch ~500Wh und ~1.4kWh., die maximale Leistungsaufnahme ist aber immer bei ~2kW, die Dauer des Aufheizens variiert hald.
    D.h.: das Program macht die Energieaufnahme ;).

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Auch hier ein "typischer" Stromverlauf MEINER Waschmaschine so wie wir sie hald verwenden:
    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Aber wie auch schon Cephalopod schrieb: dieser Stromverlauf ist von vielen Parametern abhängig - und sicherlich auch von dem gewählten Programm.

    Obwohl ich mich bei den Energieangaben bei WM nicht eingelesen habe nehme ich mal an dass die "Datenblattangabe" des Herstellers sich wohl auf ein "optimiertes" Programm bezieht, das du in der Realität wohl nie verwenden wirst. ;(

    Edit: In summe brauchte dieser Waschgang auch ~2.2kWh

    Du schaust da auf den falschen Dastenpunkt:
    ich verwende den Datenpunkt "event.xxxxxx_input_0/1" um die 2 Taster separat abfragen zu können - ein "binary_sensor" hat hald nur die Zustände "0" und "1"

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Für mich ist das ein "Fehlerzustand" wo sich das Rollo eigentlich abschalten sollte weil ein "nicht erwartetes Hindernis" erkannt wurde - z.b.: ein Sessel der in der Balkontür vergessen wurde.

    Ich habe noch eine Frage:
    Schau mal im Webinterface nach was bei dir WÄHREND der Fahrt (also NICHT im Anschlag) für Strom/Leistung angezeigt wird?
    Bist du da auch schon "in der Nähe" der 200W oder deutlich davon weg? Die Grenze sollte wohl nur knapp über dieser "normalen" Leistungsaufnahme gesetzt werden.

    Vorabfrage: Verkraftet es der Lüfter wenn 2 oder 3 der Ausgänge gleichzeitig geschaltet sind? Solange du kein Öffner/Schließer Umschaltrelay verwendest kann es immer vorkommen dass 1 Relay "hängen bleibt". Das kann sowohl durch ein SW-Problem als auch ein HW-Problem vorkommen.

    Und beachte auch dass du beim "wechseln" der Relays immer einiges an Zeit ALLE Relays ausschalten musst um dem vorher aktiven Relay zeit zu geben um sich auch WIRKLICH auszuschalten.

    Ich glaube aber trotzdem dass es auf Dauer keine gute Lösung ist wenn du das Rollo immer "gegen die Wand" fahren lässt, da wird sicherlich schnell(er) mal was kaputt.

    Eigentlich wundert mich sogar dass eine ÜBERLAST-Abschaltung, was ja eigentlich eine "Sicherheitsfunktion" sein sollte, bei der Kalibrierung als "Anschlag" verwendet werden kann ohne dass das zu einem aktiven Fehler führt. Ich dachte mir bisher dass nur das "Ausschalten des Motors durch den Motorendlagenschalter", was zu einer Leistungsaufnahme <<<10W führt, zur Erkennen der Endlagen führt :/.

    Die Anzeige des NT ist mehr eine "Hausnummer" als ein "Messwert" - also bitte ein Messgerät - wie du auch dann gemacht hast - nehmen

    Nebenbei: Der Shelly plus i4DC hat einen LDO. Diese Teile „verbraten“ die überschüssige Leistung in Wärme. Offenbar sind 9V Speisespannung ein ungünstiger Arbeitspunkt. Hast Du mal mit 5V DC gemessen?

    Aber das würde mir dann NOCH mehr sorgen machen, das würde ja dann heißen dass der Shelly plus i4DC auch bei 24V die "Icont=54mA" aufnehmen würde, was einer Dauerleistung von 24V * 54mA = ~1.3W entspricht. Das währe dann schon 30% über der Datenblattangabe, und dabei sind die "Spitzen" noch gar nicht eingerechnet...

    I have a similar problem with my MVHR, but I do not have a "defrost valve" to control.
    My problem ist that if the air humidity is too high and the outside temperature is below ~0°C the external intake filter will freeze over completely and no air at all is able to get through.

    In advance: I use Home Assistant for "my solution"
    I also used Shelly Mini's to "simple" control my MVHR by switching some external input triggers on/off. But now I use a Modbus TCP Ethernet-Adapter to get MANY datapoints and also control the MVHR through the included interface.

    The default HA "device page" of my MVHR - there are tooooooooo many datapoints to use them all ;), but some are really useful.
    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    So I now have much more control over the available functionality of my MVHR and I also get several feedback-signals of the state of the MVHR.
    => I suggest you use a Modbus-Adapter too because it has many advantages
    The MVHR itselfe will probably have the ability to control the valve!


    Additional information how I try to "solve" the problem with my MVHR + ice - perhaps it helps you somehow with your whole implementation:
    My Problem with ice: my system does not even have a defrosting functionality/valve ;( - but it would not help in my case anyway:
    I have the problem that the EXTERNAL intake filter (outside at the house wall) freezes over. There is an intake filter which seems to "accumulate" water and freezes completely over and then the MVHR does not get fresh air at all and "recycles" old air from somewhere inside - in this state there is no benefit to activate the MVHR at all and I wanted to disable the MVHR to at least save some power.

    My "solution" for this problem:
    v1) Because the simple "external temperature detection" is for my setup by fare not enough I tried to detect the difference of the temperature of my external weather station (Ecowitt Wittboy WS90) and the intake temperature of my MVHR - when the difference is >3°C (because the intake is blocked by ice and uses some internal WARM air as "intake") I shut down the MVHR completely until defrosting is "detected" (= by hand :(;().
    The Problem is: the intake is already frozen over at this point

    v2) I use the external humidity and temperature to calculate the "dewpoint temperature". If the external temperature is <= the external dewpoint temperature and the external temperature is < 0°C I shut down the MVHR BEFORE it freezes over.
    => This is still in the test phase

    Example trace:
    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Ich hatte zwar nie einen Shelly Button 1, aber einen Shelly Door/Window 2:
    Da das ein Batteriebetriebes WLAN-Gerät war, und trotzdem Batterie sparen musste, schaltete der immer sofort nach einem Event das WLAN wieder aus.
    => Das führte dazu, dass er sich BEI einem Event erst in das Haus-WLAN einloggen musste bevor er das Event absetzen konnte. Dies dauerte EINIGE Sekunden.

    Ich vermute der Shelly Button 1 verhält sich ähnlich.

    Ich war mit dem Shelly Door/Window 2 mit der Zuverlässigkeit nicht zufrieden.
    => Für mich hat der Shelly BLU Door/Window das "Problem" dann gelöst und war dabei auch noch VIEL schneller.

    Naja, Kellerabteil+Wohnungstür+Wohnungstür Schloss wundern mich nicht besonders => Das Schloss ist hald "etwas" voller.
    Welches Gerät ist denn das "Schloss"? Mich wundert dass der so oft Daten sendet.

    Das Kellerabteil ist da schon interessanter. => kann es da sein dass du eine "schlechte" oder alte Batterie geliefert bekommen hast?

    => kannst du vom Kellerabteil + Schloss mal die packet_id posten - dann sieht man wie oft bzw. OB die senden.

    Was suche ich:
    1) Die packet_id sollte sich ja eigentlich nur event-getriggert und zusätzlich in einem gewissen interval (z.b.: 1x pro Tag) um +1 erhöhen
    2) Wenn sich die packet_id immer wieder mal um mehr als +1 erhöht, dann hast du einen zu schlechten BT-Empfang vom nächstgelegenen Gateway