Beiträge von Priamos

Die Häufigkeit kannst du mit dem Kommando Teleperiod einstellen.

Meines Wissens kann man die Nachrichten von Sensor und State nicht deaktivieren.

Aber warum ist es ein Problem, wenn diese Informationen übertragen werden?

Es gibt die Unoffical Firmware-Builds hier.

Hier findet sich auch eine Variante mit Scripting

Die Dokumentation ist hier hinterlegt.

"asmota-scripting - all scripting features instead of rules + Smart Meter Interface enabled"

Ich verwendet den IR-TTL-Lesekopf von Hichi.
Die Leitung muss gelötet werden. Der Controller ist wegen WIFI ausserhalb des Zählerkastens installiert.

Läuft seit 2 Jahren völlig problemlos.

Ich verwende ein privates Repository auf GitHub.

"privat" heisst hier, nur für mich selbst sichtbar und zugänglich.

Der Account bei GitHub und die eingschränkte Nutzung sind kostenlos.

Dazu muss man sich etwas in Git einarbeiten oder man nutzt Tools wie Visual Studio Code, welche Git direkt unterstützen.

Mit Git hat man ein Versions-Kontroll-System, mit welchen sich alle Änderungen am Source-Code nachverfolgen lassen.

Man kann somit auch alte Software-Stände wieder auschecken.

Mein IDE mit Visual-Studio-Code sieht so aus:

Die linke Seitenleiste zeigt alle Dateien, welchen noch nicht via Git "committed" sind, also deren Änderungen noch nicht im Repository gespeichert sind.

Zitat von WWSolar

Ich finde aktuell keine Möglichkeit Daten von tasmota an shelly zu schicken

Ich kann dir zeigen wie man aus dem Tasmota-Scripting heraus, eine HTTP-Request absetzt, welcher Werte des digitalen Zählers beinhaltet.

Der Aufbau des HTTP-Request hingegen hängt davon ab, was das Ziel, also der Shelly, benötigt.
Ich gehe davon aus, dass auf deinem Shelly kein Tasmota läuft sondern die originale Firmware.

Kannst du den Aufbau des HTTP-Requests vorab klären ?

Zum Tasmota-Scripting gibt es hier ein Beispiel wie man per "WebSend" eine HTTP-Request formuliert.

Ich verwende selbst einen UDP-Broadcast, damit der aktuelle Stromverbrauch von mehreren Controller gleichzeitig ohne MQTT-Broker empfangen werden kann,
wie etwa in diesem Beispiel oder auch beim der Ansteuerung des Heizstabes.

Tasmota unterstützt sehr viele Hardware-Plattformen. Ich verwende hier einen Controller, welcher mit 230VAC versorgt wird, 2 Stromzähler und 1 Gaszähler erfasst.

Zitat von WWSolar

Ich möchte die Leistungswerte des Tasmota basierten Lesekopf z.b. Hichi via WiFi an einen shelly plus 2pm zur Weiterverarbeitung via Script schicken, ohne

Zwischenstation über z.b Rasperry

Ja, das funktioniert. Zumindest für tasmota kann ich das bestätigen.

Ich verwende Homematic mit der alten CCU-2 und habe eben die Erfahrung gemacht, dass aktuelle Wandthermostate nicht mehr unterstützt werden.

Ich werde mich mittelfristig wohl von Homematic verabschieden.
Mit der Sprache TCL seinen begrenzten Möglichkeiten konnte ich mich nicht wirklich anfreunden. Aktuell verwende ich das System als reinen Gateway für die vorhandenen Homematic-Geräte. Die programmtechnischen Möglichkeiten sind für mich essenziell.

ZigBee und Matter werden an Bedeutung gewinnen. Ich gehe davon aus, dass die ESP32 Familie entsprechend aufgerüstet wird, Sensoren und Aktoren gibt es dazu bereits reichlich.

Mit dem Berry-Script von Tasmota gelingt es nunmehr, komplexe Funktionalität direkt auf den Controller zu bringen, welche vorher am zentralen System umgesetzt wurden.

Mein Node-Red soll in Zukunft soweit möglich nur als Monitoring/Gateay-Service zu Einsatz kommen, ohne wichtige "produktive" Verwantwortlichkeiten.

Mit Low-Energy-Bluetooth haben alle ESP32 Controller die Möglichkeit direkt mit Sensoren und Aktoren zu kommunizieren, was ich derzeit als Übergangslösung nutze.

Die Raum-Sensoren können also direkt ohne Gateway gekoppelt werden und so etwa als Istwert für Regler dienen.

DirtyHaerry

Es gibt für Geräte unter Tasmota eine eindeutige Referenz beim genialen blakadder.

Hier findet sich zu Shelly 1 Plus

GPIO04 Switch_n 1

GPIO26 Relay 1

Die Bedeutzng zu "Switch_n" erhält man auf der Components-Seite.

Switch_n1 Switch, no pull-up resistor

Bei blakadder findet man auch die Info, welche Tasmota-Variante einzusetzen ist. (hier tasmota32solo1)

Ich selbst habe schon viele Shelly Plus 1 geflashed und das dort zu ausgewiesene Template verwendet.

Es geht noch einfacher:

Unter Configuration/Auto-Configuration wählt man das passende Template aus:

Es erfolgt ein Reboot.

Danach findet sich das Template unter Contiguration/Configure Other.

Hier darauf achten, dass die Checkbox "Activate" aktiviert ist.

Das Template wurde durch den vorherigen Schritt automatisch eingetragen.

Danach läuft alles wie erwartet.

Im Übrigen funktioniert auch Mongoose2Tasmota sehr gut , wenn man sich genau an die Anweisungen hält.

Es ist noch zu klären, ob Standard-Tasmota dauerhaft im AP-Mode laufen kann.

Das scheint nicht der Fall zu sein wie dieser Beitrag zeigt.

Mit Tasmota wäre das machbar.

Die LED ist offensichtlich auf GPIO 0 gelegt. "_i" bedeutet hier inverse Ansteuerung.

Das LED Verhalten lässt sich dann mit dem Kommando "LedState" einstellen.

In meinem Projekt "Alternatives Heizungskonzept" müssen die wesentliche Daten (Sollwert, Istwert, Boost-Status) der Homematic-IP-Thermostate (Wandthermostate oder Radiator-Thermostate)
zu den Reglern der Infrarot-Heizung übertragen werden.

Dies übernimmt die vorhandene CCU-2-Homematic-Zentrale. Sie agiert als Gateway und Nachrichten-Publisher.

Damit profitieren die Regler der IR-Heizung im genannten Projekt von den Sensoren und Settings (Soll-/Istwert, Wochenprogramme , Betriebasrt) der Homematic-Welt und können diese nutzen.

Auf den Einsatz von MQTT oder Cloud-Computing wurde bewusst verzichtet, um möglichst wenig technische Abhängigkeiten zu haben.

Folgende Anforderungsliste sollte erfüllt werden

1. der Gateway (CCU-2) muss keine Information darüber haben, wer die Daten nutzt.
2. Eine Benutzer-Interaktion (Boost-Mode-Änderung) sollte unmittelbar(< 5 Sekunden) an die IR-Regler weitergereicht werden
3. Die Daten werden zyklisch veröffentlich (published)
4. Das Datenformat der übertragenen Nachricht folgt den Grundkonzepten eines MQTT-Systems mit den Elementen Topic und Payload
5. Eine Nachricht wird immer im JSON-Format übertragen.

Die Regler-Hardware ist meist ein Shelly, aber immer mit Tasmota-Firmware, samt Berry-Skript.

Anforderung Nr. 1

Diese wird mit Hilfe von UDP-Multicast-Telegrammen umgesetzt.
In der CCU werden diese mit einem Skript generiert, welches zyklisch und/oder ereignisgesteuert gestartet wird.
UDP-Multicast verwendet eine fixe IP-Adresse und einen dezidierten Port an welchen die Nachricht gesendet wird.
Jeder interessierte Teilnehmer kann einen Multicast-Listener öffnen, um diese Nachrichten zu empfangen.

Anforderung Nr. 2 und Nr. 3

Über das Homematic-Programm "UDP-Publish" wird das Ereignis (Boost) detektiert welches unmittelbar das Multicast-Script startet.
Die Reaktiongeschwindigkeit ist deutlich <5 Sekunden.
Zusätzlich wird das Multicast-Script über einen 30-Sekunden-Timer aktiviert.

Umgesetzt wird UDP-Multicast mit dem Linux-Programm "socat", welches bei Cuxd enthalten ist.

Anforderung Nr. 4 und Nr. 5

Das Multicast-Script der CCU setzt diese Anforderung um. (Siehe Anhang)

Nachfolgend eine Beispiel-Nachricht von der CCU.

{
	"topic": "CCU/thermostat",
	"payload": {
		"DG1": {
			"ACTUAL_TEMPERATURE": 19.1,
			"SET_POINT_TEMPERATURE": 17.5,
			"LEVEL": 0.0,
			"BOOST_MODE": false,
			"WINDOW_STATE": 0,
			"HUMIDITY": 0,
			"USAGE": "Arbeiten-2"
		},
		"DG2": {
			"ACTUAL_TEMPERATURE": 18.5,
			"SET_POINT_TEMPERATURE": 17.5,
			"LEVEL": 0.25,
			"BOOST_MODE": false,
			"WINDOW_STATE": 0,
			"HUMIDITY": 0,
			"USAGE": "Schlafen-1"
		},
		"DG4": {
			"ACTUAL_TEMPERATURE": 19.4,
			"SET_POINT_TEMPERATURE": 18.0,
			"LEVEL": 0.14,
			"BOOST_MODE": false,
			"WINDOW_STATE": 0,
			"HUMIDITY": 0,
			"USAGE": "Arbeiten-1"
		}
	}
}

Zum Abschluss

Mit dem Konzept wurde ein Serverless Broker umgesetzt, welcher auf UDP-Multicast basiert.

Die CCU dient hier als Daten-Publisher.

Die Nachrichten können von interessierten IR-Controller abonniert werden.

In Tasmota wurde mit Hilfe von Berry-Skript ein UDP-Multicast-Listener eingerichtet, welcher die Nachrichten der CCU empfangen kann
und an die betroffenen Software-Komponenten (Regler) weiterreicht.

Ergebnis:

nach weniger als 1 Minute ist der Virus im "Käfig" und Shelly ist wieder erreichbar.

Ablauf:

Shelly auf neuesten Firmware-Stand 1.3.0 bringen

hello.js script zum Testen einrichten

 let greeting = "Hello world!";
 print(greeting);

Kommando zum Script-Stop-Request ermitteln:
http://192.168.178.161/rpc/Script.Stop?id=1

Test-Script starten und mit dem Script-Stop-Request stoppen.

Nun Virus einschleusen und bestehendes Hello-Script ersetzen

while(true);

"Run on startup" aktivieren und Script starten. Danach ist Shelly via http://192.168.178.161 nicht mehr erreichbar, somit ist Virus aktiv.

loop:
Reset-Button, dann mit RESTer (Firefox Extension) so schnell es geht klicken.

wenn RESTer nach 10 Sekunden immer noch Timeout meldet, zu loop: springen

Fertig, "virus" im Käfig, nach weniger als 1 Minute.

Zum Test-Ablauf:

• Firmware auf aktuellsten Stand bringen
• ich werde das im ersten Beitrage vorgestellte Script einspielen und starten.

Ist das korrekt so ?

Was soll danach passieren ?

Bei mir sind grade neue Shellies angekommen, die werden wie immer mit Tasmota veredelt.

Also kann ich das problemlos vorher testen. Ich werde berichten.

Dies wäre zum Flashen die korrekte Datei: tasmota32solo1.factory.bin.
Der Web-Installer (wie gezeigt) macht die Auswahl sehr einfach und ist zu bevorzugen.

Zitat von thgoebel

Interessant ist jedoch, daß es mir nicht gelungen ist, Tasmota auf den defekten Shelly per FTDI-Adapter aufzuspielen. Dies gelang auch ebenfalls nicht an einem funktionierenden Shelly Mini 1.

Sehr schade, hast du eines der von mir genannten Flashing-Tools im Falle von Tasmota verwendet ?

mattbue

Ich flashe alle meine Shellies mit Tasmota. Die von dir verwendete Anleitung scheint mir korrekt zu sein.

Du könntest aber auch die Getting Started Seite von Tasmota verwenden. Hier werden auch die Fehlermöglichkeiten erläutert.

Auf der seite von Blakadder kann man schnell alle Fragen zur Hardware klären:

• welches Image ist zu verwenden (tasmota32solo1)
• welches Flash-Verfahren wird vorgeschlagen
• wo liegen die Pins

Um in den Flash-Modus zu gelangen ist GPIO 0 vor dem Stecken des USB-Adapters mit GND zu verbinden. Danach kann die Verbindung gelöst werden.

Mit MongooseToTasmota32 habe ich so meine Probleme, meistens lande ich bei der alten Flash-Methode via USB_Adapter.

Ich rate zu folgendeher Vorgehensweise, welche ich selbst bei Problemen verwende.

1. Absicherung des Software-Tools zum Flashen

Hier kommen folgende Tools in Frage : ESPTool, der Tasmotizer oder der "Tasmota Web Installer"

Ich empfehle Letzteren zu verwenden (unter Edge oder Chrome), da dieser von Tasmota entwickelt wird und den höchsten Komfort bei großer Einfachheit bietet.
Man kann wählen ob man die Release-Version oder die Developer-Version (mit den letzten Änderungen) wählen will.

Ich verwende als Test-Hardware für diese Tools eine NodeMCU32 Hardware. Hier gibt es keine Verdrahtungsprobleme man braucht auch keinen Pin xy vor dem Flashen auf GND ziehen.
Einfach einstecken: fertig.

Dieser wird nun mit dem Tool der Wahl geflashed, wenn alles wie gewünscht funktioniert (HTML-seite von Tasmota ist erreichbar), hat man diesen Prozess-Schritt im Griff.

2. Anbindung der Hardware

Hier ist natürlich die korrekte Verkabelung sehr wichtig, aber auch gute Verbindungen in den Mini-Stecker des Shellies.

Ich habe hier den Zugdraht eines KNX-Kabels verwendet, der passt prima und man hat bein Stecken eine haptische Kontrolle, dass er wirklich steckt.
(man muss schon ordentlich ziehen um ihn wieder raus zu bekommen)
Ich meine hier macht man die meisten Fehler.

GPIO-0 des Shellies auf GND legen und gleichzeitig den USB-Adapter in den PC stecken.

Wenn der USB-Adapter an den PC angeschlossen wird (bei mir ist es Windows) meldet sich Windows sofort mit einem Beep, dass die ser. Schnittstelle erkannt wurde.
Nach dem Betätigen des Connect-Buttons erscheint diese auch in der Auswahl-Box des Web-Installers.

Schnittstelle wählen und "Verbinden" drücken.

Wenn die Verbindung aufgenommen werden konnte erscheint folgendes

Der Rest ist dann eigentlich klar.

Ich hoffe das hilft weiter.

Johann

JuergenAC

Zu Tasmota: es ist keine Programmierung nötig.

Einfach die Befehle. pwm und pwmFrequency sind zu nutzen.

Ich schlage vor den Test nochmal mit Tasmota zu fahren.

Ich kann dich gerne unterstützen.

Zitat von richard-os

Die 9kW passen zur Leistung der PV und auch zum Ausgleich des täglichen Wärmeverlusts

Bei dieser Größenordnung solltest du in Betracht ziehen einen professionellen Anbieter zu wählen. (MyPV, Technische Alternative TA mit Thor)

In aller Regel ist der Einsatz der Schwingungspaket-/Wellenpaketsteuerung vom Versorger durch die "Technischen Anschluss-Bedingungen" = TAB limitiert.

Diese sollten vor dem Projektstart überprüft werden.

Ich habe gelesen, dass etwa TA nur eine der 3 Phasen moduliert, die beiden anderen werden bei Bedarf einfach zugeschaltet.

Das wäre auch bei Nutzung der Schwingungspaketsteuerung anzudenken.

Johann

Danke für die schnelle Antwort,

Hättest du die Optimierungen nicht durchgeführt, wäre der Heizungsbauer nicht von 14 MWh sondern von 21 MWh Energiebedarf ausgegangen.

Dann läge der erwartebare Strombedarf bei ca. 5000 kWh.

Auch die Überschlagsrechnung liefert liefert ein ähliches Ergebnis.

21.000 kWh

Wirkungsgrad Therme 80% ==> 16800 kWh

JAZ konservativ mit 3 => 5600 kWH

https://www.ise.fraunhofer.de/de/presse-und-…verlaessig.html

Zitat

Die Anlagen erreichten Jahresarbeitszahlen (JAZ) von 2,5 bis 3,8. Der Mittelwert lag bei 3,1.

Damit ist JAZ 4.1 ist ein sehr sportliches Ziel.

Johann