Beiträge von Priamos

Krauskopp

https://github.com/aelias-eu/hewa…eco%20Proto.pdf

Wie wär’s damit?

Stammt von dieser Seite
https://github.com/aelias-eu/hewa…=readme-ov-file

Ich habe mich mit den DS18B20 auch schon einige Zeit geplagt. Die Teile sind super wenn man auf die Schnelle Temperatur überwachen will.

Wenn man jedoch Zuverslässigkeit in einem belasteten Umfeld braucht taugen sie nicht wirklich. (z.B. neben Hocheffizenz-Pumpe)

Daher teste ich gerade einen PT1000 Messumformer mit Modbus RTU.

RS485 ist der oft verwendete Übertragungsstandard in der Industrie und wegend der differenziellen Übertragung höchst störsicher.

Tasmota hat einen Modbus-Master integriert, so dass die Erfassung gut möglich ist.
Die Werte stehen dann im Skript zur Verfügung

Mit einem preiswerten TTL/RS485 Adapter kann das sicher auch am Shelly Plus Uni verwenden.

Generell finde ich den Ansatz Peripherie (Relais, Messwerte) über Modbus zu koppeln immer attraktiver,
da meine Augen zum Löten nicht besser werden.

Die Elektronik sieht vertrauenswürdig aus. Der Support ist eher mäßig und bisher auf chinesisch.
Aber das Teil macht was es soll und ist wirklich sehr günstig.

Den ebenfalls erworbenen chinesischen PT1000 Sensor mit 5m Kabellänge habe ich mit einem von TA verglichen , beide zeigen bis auf 0.1 Grad denselben Wert.

Sieht bisher gut aus. Alles nur auf dem Labortisch. Der harte Einsatz folgt noch.

Zitat von Mig1957

Ich habe jetzt schon mehrer Shellys mit Tasmota flashen können, früher mit einem FTDI Adapter,

Das ist auch bei Shelly plus 1 möglich

Zitat von WWSolar

Kann diese auf die selbe weiße ausgelesen werden wie die Info Schnittstelle?, also mit dem bitShark Lesekopf?

Ich hatte vor einiger Zeit auch einen EBZ-Zähler mit einem Hichi-Sensor und Tasmota ausgelesen.

Ich kann bestätigen, dass die MSB-Schnittstelle ebenso funktioniert, wie die Front-seitig und weitaus mehr Daten liefert.

Dies war der Aufbau:

erster Test: Front, Magenthalter 

1-0:0.0.0*255(1EBZ0101187989)
1-0:96.1.0*255(1EBZ0101187989)
1-0:1.8.0*255(004913*kWh)
1-0:2.8.0*255(000001*kWh)
1-0:96.5.0*255(001C0104)
0-0:96.8.0*255(029C608B)

zweiter Test: MSB Schnittstelle ,nicht front, sondern oben am durchsichtigen Teil

1-0:0.0.0*255(1EBZ0101187989)
1-0:96.1.0*255(1EBZ0101187989)
1-0:1.8.0*255(004914.26955262*kWh)
1-0:2.8.0*255(000001.19400000*kWh)
1-0:16.7.0*255(000331.62*W)
1-0:36.7.0*255(000181.33*W)
1-0:56.7.0*255(000113.91*W)
1-0:76.7.0*255(000036.38*W)
1-0:32.7.0*255(225.4*V)
1-0:52.7.0*255(224.7*V)
1-0:72.7.0*255(226.2*V)
1-0:96.5.0*255(001C0104)
0-0:96.8.0*255(029C70FD)

Zitat von hahgeh

Ok, dann spricht nix dagegen den mit 230v zu versorgen für das Projekt.

Doch,absolut. Die in Beitrag #1 vorgestellte Schaltung sollte in keinem Fall mit 230 VAC betrieben werden.

GPIO 19 wird zum Ansteuerung des PWM-Eingangs der Lüfter verwendet, welche mit 12 VDC versorgt werden.

Das Potential von GPIO 19 ist bei 230 VAC Versorgung nicht auf die DC-Spannung bezogen sondern liegt im AC-Bereich.

Dies gefährdet den Shelly, den Lüfter oder auch Personen.

Edit by Moderator, Gefahrenhinweis verstärkt.

Hersteller der erwähnten Smart Home Bridge ist offensichtlich Mediola.

https://blog.mediola.com/jalousiescout-…aio-creator-neo

https://matter-bridge.com

Ich habe mich vor einiger Zeit lange rumgeschlagen mit der Anbindung der Jarolift-Motoren.

Das "BastbubenProjekt" habe ich mit viel Aufwand nachgebaut und schien zunächst zu funktionieren.

Problem war die Langzeit-Stabilität, das Teil hat sich immer wieder verabschiedet nach wenigen Wochen.

Ich habe mir dann die SmartHomeBridge besorgt und bin damit sehr zufrieden.

(regelmässiger Updates, Funktionalität ...)

Diese wird mit einer installierbaren App bedient und beherrscht darüber hinaus auch Matter.

Wer mit dem Gruppen, Rules und Szenen der Bridge zufrieden ist, braucht keine Einbindung in ein übergordnetes System.

Ich habe damit 8 Motoren gekoppelt.

Wie man Tasmota auf die Geräte bekommt findest du hier https://templates.blakadder.com/shelly_RGBW2.html

Das ist die beste Seite, um zu sehen, für welches Gerät sich welche Flash-Varianten eignen.

Zitat von funkenwerner

..., hab das noch nie Verstanden warum man das machen will, aber jedem das seine

Da Tasmota schon länger Matter unterstützt, kann dies ein Grund sein sich dafür zu entscheiden.

Ich habe mir über die Jahreswende eine Modbus-Scanner gebaut, welcher meinen Wechselrichter ausliest und alles auf MQTT published.

Keine Ahnung, ob die Shelly Firmware Modbus als Master unterstützt. Bei Tasmota ist das in jeder Firmware-Variante integriert.

Diese Seite wird direkt vom Controller geliefert

sailmich

Laut Intel Spezifikation für PC-Lüfter gilt:

Zitat

target frequency: 25kHz, acceptable range 21kHz to 28kHz

Ich verwende 25 kHz PWM-Frequenz mit dem Befehl

pwmfrequency 25000

Man sollte noch die bei LED-Ansteuerung übliche Gamma-Korrektur deaktivieren via

SetOption15 0

Dannach kann man im Bereich von 0..1023 das Puls/Perioden Verhältnis einstellen

pwm 500

Zitat von BlackLotus

Das hast Du aber alles selber gebaut/programmiert, richtig? Oder gibt es dazu allenfalls irgendwelche Vorlagen, Blogposts, o.ä.?

Nicht alles, das meiste ist schon in Tasmota BLE behandelt https://tasmota.github.io/docs/Bluetooth_ESP32/ .

Dies war mein initales Projekt.

Diese Sensoren senden

Zitat

BLE advertisement packets with a certain data structure, which are broadcasted by the devices automatically

Es ist also keine Bluetooth-Session vorhanden, die Nachricht kann von mehreren Gateways gleichzeitig erfasst werden.

Zitat von BlackLotus

Wie verhinderst Du beim ersten BLE-Telegramm (wenn die Gateways die BLE-Devices noch nicht kennen), dass Aktionen mehrfach ausgelöst werden?
Wie verhinderst Du eine Mehrfach-Auslösung allgemein ausserhalb der Timeout-Zeit? Dann kann der Broadcast ja (je nach Timing) mehrfach ausgelöst werden, oder?

Das kann tatsächlich passieren, wenn sich die BLE-Gateways noch nicht ausreichend "kennengelernt" haben.

Dies ist in meinem Fall kein Problem, da ja Sensor-Werte (Temperatur u. Feuchte) übertragen werden.

Mir war hier die Redundanz wichtig, so dass das System nicht blind wird, wenn ein Gateway ausfällt.

Insgesamt sind 4 Gateways verteilt auf 3 Etagen im Einsatz (alles Shellys Gen. 2), deren Empfangsbereiche überlappen.

Zitat

Ich nehme mal an, es gibt eine Filterung der eingehenden UDP-Nachricht(en) auf den Aktor-Device (also das Device, das dann irgendwas ausführen soll) auf Duplikate oder etwas ähnliches?

Die Nachricht ist wie bei MQTT über Topic/Payload strukturiert. Das Consumer-Device kann sich auf das gewünschte Topic subscriben.

Im Callback-script kann dann alles weitere erledigt werden.

Das sieht dann etwa so aus auf Consumer-Seite (mit Berry-Script)

def UdpMessageHandler(topic,payload)
  print("UdpMessageHandler received topic:",topic," payload:",payload)
end

udpBroker = UdpBroker("broker")
udpBroker.subscribe("MyCoolTopic",UdpMessageHandler)

Zitat von BlackLotus

Keine Cloud-Verbindung notwendig
Kein separater "SmartHome-Server" (HomeAssistant, ioBroker, usw.) notwendig
Funkabdeckung im ganzen Haus und Garten (entspricht der WLAN-Abdeckung), Roaming zwischen WLAN-Access-Points

Auch mir sind einige der genannten Aspekte, wie zitiert, wichtig.
Meine Lösung habe ich mit Tasmota umgsetzt, so beschreibe ich hier nur die Grund-Prinzipien.

Ob und wie sich das unter Mongoose umsetzen lässt , darüber kann ich mangels Erfahrung nichts sagen.

Die BLE-Gateways versenden die Informationen über die empfangenen BLE-Telegramme via UDP-Broadcast.

Diese Verfahren ersetzt den "Smart-Home-Server", da UDP von jedem TCP/IP fähigen Gerät empfangen werden kann.

Somit kennt jeder BLE-Gateway nach dem Start die Empfangs-Qualiät der BLE-Devices bezogen auf jeden anderen Gateway.

Sobald Gateway A erkennt, dass Device X bei Gateway B besser empfangen wird, stellt er zu diesem Gerät seinen eigenen Broadcast-Nachrichten ein. Dies gilt für eine festgelegte Timeout-zeit von z.B. 5 Minuten.

Die UDP-Broadcast Nachrichten werden alle 60 Sekunden gesendet (Temperturen..) , bzw. nach einem Ereignis (Taste gedrückt).

Der Übergang von BLE auf TCP ist somit ausfallsicher, ohne SmartHome-Server umgsetzt.
Alle Devices können die UDP-Nachrichten konsumieren und verwerten.

Die Nachricht selbst ist analog zu MQTT via Topic/Payload organisiert.

Zitat von Spieltrieb1

Möchte unter einem Heizkörper 12 Volt/5 PC Lüfter montieren die bei aktiver Nutzung diese nicht nur ansteuert sonder bei steigender Temperatur diese Lüfter auch noch von der Leistung hoch dimmt mit dem Signal von 0 bis 10 Volt.

Man kann das mit einem Shelly zusammen mit tasmota umsetzen.

Beitrag

Smarter Heizkörper-Ventilator mit Shelly Plus 1

Mit einem Shelly Plus 1 + Tasmota-32 kann man einfach einen smarten Heizkörperventilator bauen.

Zum Einsatz kommen preisgünstige PWM-fähige PC-Lüfter, die mit Magneten an der Unterseite des Heizkörpers befestigt werden.

Gegenüber kommerziellen Lösungen (wie SpeedComfort) bietet das vorliegende Konzept folgende Vorteile:

• die Größe der Lüfter kann passend zu den Maßen des Heizkörpers gewählt werden
• die magnetische Halterungen können optimal positioniert werden
• die Verteilung der Lüfter über die

…

Priamos

1. August 2023 um 09:32

@lichtganzaus

Interessant deine Erfahrungen und gut dass du diese teilst.

Das Angebot vom Heizungsbauer für eine BWWP vor etwa 2 Jahren lag bei > 5000 EUR.

So bin ich bei meiner 600W Heizpatrone geblieben, welche im 160l Boiler steckt und ganzjährig für Warmwasser sorgt.
In den Monaten April bis Oktober wird der größte Teil der Energie von 4KWh/Tag über PV beigesteuert.

Im Winter unterstützt die Gasheizung, indem während der Brennerphase die Ladepumpe für den Boiler aktiviert wird und so der untere kälteste Teil des Boilers auf die Heizungs-Vorlauftemperatur vorerwärmt wird.
Die Gasheizung fährt keinen Warmwasserzyklus mehr. Den letzten Temperaturhub im Boiler übernimmt also der Heizstab.

Damit reduziert sich der elektrische Energiebedarf auf ca. 1-2 KWh/Tag für Brauchwasser bei einem 2-Personen-Haushalt in den Heizmonaten.

Die erwartbare Lebensdauer einer BWWP würde ich mit 15 Jahren ansetzen (Erfahrungswerte meines Nachbarn).
Damit würde sie zu Lebzeiten die Investition nicht einspielen können.

Relais 1 mit AutoOFF in 300 Sekunden

Pulsetime1 400

Dasselbe für Relais 2

Pulsetime2 400

Die Commands können in der Console eingegeben werden, die Werte für Pulstime sind dauerhaft gespeichert und auch nach dem nächsten Reboot gültig.

Die Zuordnung in der Matter-Config erfolgt somit über die Relais-Nummer.

Suche nach dem Command PulseTime.
https://tasmota.github.io/docs/Commands/#control

Das sollte weiter helfen.

Ich meine erst musst du die enge Verbindung zwischen Eingang und Relais auflösen ( Detach).
danach löst eine Änderung am Eingang einen Event aus.

dieser kann ein Berry Skript starten, in welchem sich jeder exotische Ablauf abbilden lässt.

Ich verwende einen IN Z65 zusammen mit Tasmota auf einer Nodemcu. Das funktioniert seit Jahren völlig problemlos.

Zitat

„Zyklisches Programm(Script) < 500ms erhöhte Crashneigung“

Wenn dem so ist, dann ist das eher eine Frage, was du in dem Skript machst, bzw. wie die Firmware mit damit umgeht.

In Berry-Skript würde ein zyklischer Callback nach 50 ms so formuliert werden:

class MyDriver
  def every_50ms()
    # do something
  end
end

d1 = MyDriver()

tasmota.add_driver(d1)

Hallo Jürgen,

ich weiss nicht ob dir das hilft, trotzdem eine Bemerkung aus Sicht eines Tasmota-Enthusiasten.

Das Script-Sprache unter Tastmota nennt sich Berry.

• es gibt keine Einschränkungen bezüglich der Anzahl der laufenden Skripte
• alle Scripte der Anwendung können in eine gezippte Datei kopiert werden und werden beim Starten von Tasmota automatisch geladen (Einfaches Deployment)
• man kann die Source-Files sehr gut strukturieren (1 File pro Klasse)
• Die API bindet sich eng in die Firmware ein, so dass auch die UI umfassend manipuliert werden kann.
• die Sprache lehnt sich an Python an
• man kann Teile der eigenen Skripte direkt in die Firmware einbinden um RAM zu sparen (Solidifying)

Die wichtigere Frage ist eher, was willst du damit machen oder erreichen.

Geschwindigkeit würde ich daher erst mal nachrangig betrachten.

Johann

Zitat

Hast du dich evtl. mit der Grafik „Monatsverbrauch Gas & WW“ vertan?

Aufsummiert kommst du da locker unter Brüder was um die 27000 kWh , wobei du ganz oben „Gasverbrauch neu“ 12000 kWh plus Heizstrom 5000 kWh geschrieben hast

Der Plan-Verbrauch nach Abb 12. bzw. Abb. 13 ist jener vom Alt-System. In Abb. 3 wird dieser mit 29.000 kWh ausgewiesen.

Der Ist-Verbrauch (Abb. 13) ist jener vom Neu-System. Die Einsparung ergibt sich aus der Differenz von beiden.

"Gasverbrauch neu" wird in Abb. 3 mit 12.000 kWh dargestellt.

In Abb. 5 findet sich die Gas-Einsparung mit 17.000 kWh und der Heizstrom mit 5.000 kWh (welcher ja die Einsparung ermöglicht).

Ich sehe hier keinen Widerspruch.