NEWS

@bananajoe Das ist ja die einfachste Übung, den Switch auszuleiten ...

mit dem Blockly oder Javascript bzgl JSON Zerlegung tue ich mich da deutlich schwerer...
Womöglich lasse ich den ESP erstmal unter Sonoff ...

@vool

Ja, das scheint es öfter zu geben. Habe auch schon ein paar ESP Module rumliegen die sich abnormal verhalten 😞
Ärgerlich, da man damit ja nicht unbedingt rechnet und dann eine Menge Zeit verplempert rauszufinden warum es nicht funktioniert.

Viel Spaß noch.

@martinp
Hab jetzt ein 3. Kabel genommen und jetzt klappt es wieder.
Keine Ahnung warum, bisher haben die Kabel immer geklappt.

Egal, wenn es jetzt wieder geht ist alles gelöst 🙂
Manchmal einfach nicht Lösungen hinterfragen sondern einfach akzeptieren

@mico bei einem 1PM ist die aktuelle FW 20230913-113709/v1.14.0-gcb84623
von einer beta seh ich da nix.
bei shelly kannst du ruhig auch ne beta insten, danach wird dir ein button angezeigt um zur letzten stable zu flashen, sollte es probleme geben.

@bananajoe danke für die Antwort. Habe scheinbar das falsche rs485 Modul genommen. Werde es mit dem neu bestellten dann ausprobieren.

@jhuebner1

Oder du versorgst den BH1750 wie nicht selten mit 5V und der murksige Spannungsregler ist außen vor. Einen Level Shifter dann aber für den I2C zu nutzen kann ich nur als positiv empfehlen der mir einen sehr langen stabilen Betrieb eines BH1750 ermöglicht. Das Ding rennt jetzt etwas seit 2,5Jahren ohne Zicken.

Elkos altern also würde ich das vermeiden.

@codierknecht Geht sicher auch gut.
In meinem Fall habe ich jede Menge Inspektionslampen rumliegen. Die kosten mich nix und sind überall verfügbar.

@martinsu
Ich habe den schnellen Weg gewählt und den Schalttransistor für die weißen LEDs an GPIO4 angelötet, also parallel zu der eingebauten Blitz-LED.
GPIO12 logischerweise deaktiviert und GPIO4 aktiviert.
Ich habe dann MQTT Broker/Client Adapter installiert und damit funktioniert alles.

@martinsu Die ESP-Verbauer / Library-Programmierer vermeide es ja tunlichst, überhaupt eine Einheit hinter die RSSI-Werte zu schreiben ...
Die Werte werden wohl nur in einem Gerätetyp einigermaßen vergleichbar sein...

https://de.wikipedia.org/wiki/Received_Signal_Strength_Indication

Ausführlicher ist der englische Artikel

https://en.wikipedia.org/wiki/Received_signal_strength_indicator

.. There is no standardized relationship of any particular physical parameter to the RSSI reading. The 802.11 standard does not define any relationship between RSSI value and power level in milliwatts or decibels referenced to one milliwatt (dBm). ...

Ich danke euch allen sehr, ich habe endlich ein Signal!

29a55b6d-285b-42c6-ac02-1d16efd26bbc-grafik.png
Einer meiner Sensoren ist offensichtlich tot, der andere liefert werte, die sich auch ändern. Kalibriert wird das Teil dann morgen.

Ich finde 1300ppm also 0,13% CO2 in der Atemluft in meinem Büro, wo ich erst 20Minuten erstmal etwas hoch.

Dann schau ich mal, wie Amazon die Rückname organisieren möchte.

LG
Daniel

@bananajoe Ja klar. Ein Lader pro Phase ist ideal, max 9kW Ladeleistung! Das schafft fast ein neuer Pack (EVE MB31 314Ah, in 16S also 16kWh also 0.5C 8kW) 🙂

Hat sich erledigt

ich habe RX und TX sowie A und B bisschen getauscht

dann irgendwann den ESP Reboot

und schon waren Werte da

@maddin77 said in ESPEasy Rules Mehrfach Trigger und Timer:

Aktuell nutze ich 2 Switch um den Schalter zu erkennen, da ein 3stellungsschalter verbaut ist
der Manuell umgeschaltet werden soll, kein MQTT
also meinst du aus
AutoEin=1 und ManuEin=0 -->Automatik
AutoEin=0 und ManuEin=1 -->Manuel
AutoEin=0 und ManuEin= oder AutoEin=1 und ManuEin=1 -->Aus

Denke ja. Für mich ist das DummyDevice ein Merker der einen bestimmten Status wiederspiegelt. Der Status wird immer irgendwoher getriggert. Das würde ich logisch separat programmieren über Trigger. Funktionieren die Stati würde ich mich an die Aktionen machen die die Stati auslösen/bedeuten. Hierzu reicht aus meiner Sicht der "saubere"/definierte Grundzustand beim Booten und dann getriggert die Aktionen der GPIO ausgelöst durch Änderung der Stati.

Alternativ zum Dummy Device könnte man das auch über ein Event lösen. Deine Schalter lösen ein Event aus und Schreiben Aus, Auto,Man in den Log. Du wiederum triggerst dann für die Aktionen basierent auf diese Events wieder deine GPIOs. Sehe ich nur als Alternative aber keine wirklichen Vorteile...

der Plan ist
Rule1 die Relais über die Stufen aus MQTT zu schalten
Rule2 ist eine Temperatur Sicherung für ein Lastrelai
Rule3 war die Umsetzung der 2 Switch auf ein Dummy mit 3 Stellungen

Du hast das oben schon mal so geschrieben. Da bin ich nicht genug im Thema, wäre aber vorsichtig übergreifend über mehrere Rules zu arbeiten. Vermute da geht nicht alles und es gibt bestimmt Timingprobleme etc etc. Alle Triggerungen um Stati (DummyDevices) zu setzen auf einer Rule und die Trigger und Aktionen aus einer Statiänderung auf einer anderen Rule dürfte funktionieren. Aber allgemein sollte doch da genug "Platz" sein um das in einer Rule zu lösen....wäre mein Favorit um dort keine Probleme zu erwarten.

@darkiop

%YAML 1.1 --- # This is a ser2net configuration file, tailored to be rather # simple. # # Find detailed documentation in ser2net.yaml(5) # A fully featured configuration file is in # /usr/share/doc/ser2net/examples/ser2net.yaml.gz # # If you find your configuration more useful than this very simple # one, please submit it as a bugreport define: &banner \r\nser2net port \p device \d [\B] (Debian GNU/Linux)\r\n\r\n connection: &con0096 accepter: tcp,localhost,2000 enable: on options: banner: *banner kickolduser: true telnet-brk-on-sync: true connector: serialdev, /dev/ttyS0, 9600n81,local connection: &con1096 accepter: tcp,localhost,2001 enable: on options: banner: *banner kickolduser: true telnet-brk-on-sync: true connector: serialdev, /dev/ttyS1, 9600n81,local connection: &con0192 accepter: tcp,localhost,3000 enable: on options: banner: *banner kickolduser: true telnet-brk-on-sync: true connector: serialdev, /dev/ttyS0, 19200n81,local connection: &con1192 accepter: tcp,localhost,3001 enable: on options: banner: *banner kickolduser: true telnet-brk-on-sync: true connector: serialdev, /dev/ttyS1, 19200n81,local

@Dieter_P
Doch gelöst....

habe eine andere Tasmato bin gefunden (BMP280), mit der klappt es jetzt......
Danke für den Support hier.

@bananajoe Danke, das klingt schlüssig ... Frigate ist schon sehr schwatzhaft, was Topics angeht ...
(13 Ordner unter einem Kamera-Knoten... da habe ich auf das Zählen der Datenpunkte in den Unterordnern verzichtet ...)

@msco Nein, das ist wahrscheinlich anders.

Ich habe solch eine Klingelanlage nicht. Die Aussage im englischen Forum ist, dass es so lange klingelt, wie eine Brücke zwischen Klemme G und Klemme b vorhanden ist. Das kann eine Drahtbrücke für Tests oder der Kontakt eines Relais sein...

Ich würde vor Tests mit so einer Drahtbrücke ggfs. mit einem Multimeter schauen, ob zwischen b und G eine Spannung liegt, und was mit der Spannung passiert, wenn ein vorhandener Klingelknopf betätigt wird.

Falls zwischen den Klemmen eine Spannung anliegt, solange es NICHT klingelt, und sobald ein Helfer eine vorhandene Klingeltaste betätigt, bricht die Spannung zusammen könnte man gefahrlos die Brücke testen ... wenn man damit erfolgreich die Klingel auslösen konnte, könnte man statt der Brücke den Relaiskontakt (Schließerfunktion) zwischen die Klemmen schalten...

@wolfgangfb

So, die ESPs sind da, also: Die SMD Antenne taugt wirklich nur wenn der Repeater in direkter Sichtweite ist, schon durch eine Sperrholzwand in 4 Meter Entfernung habe ich ein Signal von -89 dBm was absolut Gernzwertig ist. Der C3 mit eternerner Antenne ist da deutlich besser (was auch zu erwarten war), je nachdem wo er sich im Vergleich zum Repeater befindet sind das Werte um die -65 dBm. Den C3 Core bekomme ich nicht geflasht, hat jemand eine Idee was man da beachten muss um den zu flashen?