NEWS

So, ich habe das mal aufgedröselt...
tasmota1.jpg tasmota2.jpg Das sind die Einstellungen in Tasmota
iob2.jpg iob1.jpg
Das ganze meldet sich ähnlich wie meine RGB- Stripes aber mit der Bedienung komme ich nicht zurecht.
Power1 hängt mit Red zusammen (LED-Stripe1)
Power2 hängt mit Green zusammen (LED-Stripe2):
Wenn beide leuchten lässt sich die Helligkeit regeln.
Wenn ich jetzt im ersten Bild die Helligkeit Green auf 50% setze geht Power2 automatisch auf On mit dem WErt von Green, weil sich scheinbar Color ändert.
Ich habe eigentlich nur Setoption68 auf 1 gesetzt.
Muss ich noch etwas ändern?

Help, I'm Lost... oder funktioniert das so nicht...

Jürgen

@jörg-menke
Nach Aufspielen einer neuen Firmware die mir von Hichi bereitgestellt worden ist, läuft es jetzt. Problem gelöst mit Version 14.6.02. Danke Hichi!

@asgothian
die README war an der Stelle mit dem Bild veraltet. In dem Konverter steht aktuell die online Quelle für das Bild (als Verweis auf das Repo), wodurch das Kopieren ganz entfällt.

@clausmuus sagte in Zigbee Konverter für ESP32-C6:

@asgothian
Ich werde das in den nächsten Tagen testen.
Die Namensgebung (ESP32-c6.js) ist allerdings nicht so günstig, da der Converter ja nur für die electrical_measurement_ac passt. Besser wäre also z.B. ESP32-c6-electrical-measurement-ac.js
Alternatiev könnte der Converter aber auch nach und nach für die anderen Beispiele erweitert werden, was wohl die schönere Lösung wäre.

So war das geplant - damit nicht zu viele einzelne Dateien dazu geladen werden.

@perladd sagte in ESP Wassersensor BLE-Y01 MQTT:

@homoran

Der Wassertester hat die Bezeichnung

BLE-YC01

dann passe das bitte in drinem Startpost und in dem Threadtitel an!

zu dem Typ gibt es außerdem, wie verlinkt, bereits einen Thread

@dieter_p kein altes Smartphone in der Schublade?
Ich weiß aber nicht, ob die Access Points, die Android aufspannt Verbindungen unter den Clients erlauben

@wildbill

Danke für den Tipp. Ich hatte Tasmota Basic genommen und Switch_n

Mit Generic wird auch jetzt ein Switch in ioBroker generiert, jedoch steht er immer auf true.

Wenn ich jetzt bei dem Sensor die Sensibilität voll auftrehe, müsste ich ja ständig low also false haben.
Das einzige was zuckt ist "Power". Aber nur wenn ich die Sensabilität verstelle, nicht bei Schall.

Vielleicht ist bei einem Schallsensor auch eine andere Einstellung notwendig.

@alex-8

Ich habe mir mal einen der für Tasmota empfohlenen Transceiver besorgt (SRX882/STX882) und habe den auf 'nem Breadboard fliegend verdrahtet. Funzt perfekt.
Ich habe dann kurzerhand den STX882 "huckepack" auf eine bereits verbastelte Sonoff-Bridge gesetzt und mit GPIO14 verbunden.
Funktioniert einwandfrei. Die Bridge liefert quasi nur noch die Basis (Gehäuse, MCU, Stromversorgung). Senden tut der kleine STX882.

@bananajoe
@bahnuhr

Also, Kinderkriegen ist einfacher.
Gestern Mittag war alles tutti, ESP32 mit Tasmota bespielt, Jumperkabel verbunden , im Carport verbaut.
Dann fing es an. Keine WLAN Verbindung mehr. Egal was ich auch gemacht habe. Das Teil blieb nicht erreichbar.
Also eine Alternative gesucht. ESPEasy gefunden. Naja, Easy ist dann doch gelogen in dem Namen 🙂
Hab, wegen der WLAN Reichweite diesmal einen ESP8266 genommen.
Ein Drama da ESPEasy (die richtige Version) draufzubekommen.
Nun gut. Irgendwann gegen Mitternacht hatte ich es dann. Also ins Carport, verbinden. Da der Platz da fummelig ist, ist dann natürlich die USB Buchse abgebrochen.
Also laut: Schei.... geschrien
Dann wieder den ESP32 rausgekramt, da ESPEasy drauf. Auch da war es ne Kunst die richtige Version zu treffen.
Mittlerweile war es 1Uhr und es funktionierte einfach nicht. Immer Distance 0,00 cm.
Pennen gegangen. Eben nochmal alles von vorne. Neue Jumperkabel, neue GPIO Belegung.

4f906cbb-e1e2-4251-a464-8590311d4611-grafik.png

Ich melde Vollzug um 11:42Uhr.
Diese Verbindung lasse ich da hängen, bis das Carport weggefault ist 🙂

@jens-g deine Entscheidung. Allerdings merkt sich der Adapter durchaus den “Namen” des Gerätes - nicht aber die ID, die für die Ansteuerung verantwortlich ist. Das mit dem Posten der Info Anzeige (nach deinen Änderungen) war ernst gemeint.

Das was du als externen Konverter von mir bekommen hattest war dürneine Lampe, nicht für einen Sensor.

A.

@homoran said in JK-BMS über RS485 mit ESPHome auslesen:

Punkt 1:
Da muss jemand die Energie und das Können haben den BT Verkehr mitzuschneiden und das Kennwort auszulesen.

Nö, wenn jemand weiß dass es ein JK BMS ist kann er ohne ein Passwort sämltliche Einstellungen nach Belieben verstellen.

Alles was er braucht ist die öffentlich bekannte MAC Adresse und den hier besprochenen Github-Inhalt auf einem ESP32.

Zum Glück lässt sich BLE ja im BMS deaktivieren und alles auch über UART-TTL Anbindung per Kabel nutzen.

@blockmove Muss ich mal versuchen, wenn ich genug zeit finde

@ullij said in Stromzähler mit Kauf/Verkauf Option in iobroker.:

@andre1de sagte in Stromzähler mit Kauf/Verkauf Option in iobroker.:

Mein oben beschriebenes Problem konnte ich übrigens durch den Vergleich mit früheren Daten lösen.

Wenn die Werte für Bezug und Einspeisung aktualisiert bzw. geändert werden geht das auch damit...zumindest grob im Rahmen der zeitlichen Auflösung. Mit Hilfe der aktuellen Leistung geht es halt etwas präziser.

die Variante von mir war OBIS, vielleicht funktioniert ja auch die Version mit SML ... good luck

Nein, deine Code funktioniert nicht, aber wie gesagt, ich kriege problemlos meine Hauptwerte. Und ich habe noch im Forum von tasmota gefragt, ob schon neu Code gibt.

@homoran ok danke euch

@mcu said in Sonoff-Adapter findet einen Wert vom Device nicht:

Ich bin da nicht mehr im Thema, aber die Idee wäre den Wert vom Attribut "Range" der vom Adapter nicht abgefangen wird, umzusetzen auf einen definierten Wert (vom Adapter) .

Danke, das hat funktioniert!

__

@jan1 said in Sonoff-Adapter findet einen Wert vom Device nicht:

@topsurfer
Erstelle den DP manuell und schau ob er vom Adapter befüllt wird. Habe ich bei einem fehlenden DP im Shuttermodus auch so gelöst und da funktioniert es.

Probiert, aber der Wert bleibt immer 0 (auch ESP restart, Bodenfeuchte geändert, ...)
Hab den DP vom Typ "Zahl" angelegt

{ "common": { "name": "Range", "desc": "Manuell erzeugt", "role": "state", "type": "number", "read": true, "write": true, "def": 0 }, "type": "state", "native": {}, "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1746117283884, "_id": "sonoff.0.Zisterne #e11.Range", "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }

2025-05-01_185334.png

@hardy-1

2 Minuten ist wenig zweckmäßig. PIN aus und Info ein hast Du probiert?

Hallo,

es ist ein DD3 Zähler, der wird auch von Tasmota unterstützt und ich kann auslesen: https://tasmota.github.io/docs/Smart-Meter-Interface/#ebz-dd3-obissml

Der esp32 so

@1topf sagte in Tasmota - SML - Modbus:

Aber ich vermute, daß Dein gekaufter Lesekopf (noch) nicht Modbusfähig ist. Das hätte der Verkäufer gleich mit reinkompilieren müssen. S

Das modbus-Modul ist zwar kompiliert, meines Erachtens benötige ich es aber nur, wenn ich Modbus ASCII verwenden will.
Ich möchte jetzt "nur", dass der esp32 als Modbus Server/Slave arbeitet. Er lauscht nach Anfragen und sendet dann. Das dürfte nur eine normale serielle Kommunikation sein, da habe ich gerade diesen Abschnitt gefunden https://tasmota.github.io/docs/Scripting-Language/#serial-io-support

Ich muss den esp32 jetzt dazu bekommen, die ganze Zeit die seriellen Anfragen zu prüfen und entsprechend darauf reagieren. Jemand eine Idee?

Ich habe es mit einer Rule geschafft:

Rule1 ON Button1#State DO Add1 1 endon on var1#state==1 DO Backlog Power1 1; Power2 1; Power3 0; Power4 0 endon on var1#state==2 DO Backlog Power1 0; Power2 1; Power3 1; Power4 0 endon on var1#state==3 DO Backlog Power1 0; Power2 0; Power3 1; Power4 1 endon on var1#state==4 DO Backlog Power1 1; Power2 blink; Power3 blink; Power4 1 endon on var1#state==5 DO Backlog Power1 0; Power2 0; Power3 0; Power4 0; Var1 0 endon

EDIT
Mit Backlog0 bekommt man die Versögerung fwischen den Befehlen weg. Dann sieht alles was flüssiger aus.

Rule1 ON Button1#State DO Add1 1 endon on var1#state==1 DO Backlog0 Power1 1; Power2 1; Power3 0; Power4 0 endon on var1#state==2 DO Backlog0 Power1 0; Power2 1; Power3 1; Power4 0 endon on var1#state==3 DO Backlog0 Power1 0; Power2 0; Power3 1; Power4 1 endon on var1#state==4 DO Backlog0 Power1 1; Power2 blink; Power3 blink; Power4 1 endon on var1#state==5 DO Backlog0 Power1 0; Power2 0; Power3 0; Power4 0; Var1 0 endon

@krodon sagte in ESP32C6 als zigbee Sensor:

@asgothian Danke für die Info, ich habe mich kurz im Tuya Developer eingelesen. Welcher Coordinator ist empfehlenswert? Er sollte nicht mit USB angeschlossen werden, lieber WLan. Außersem sollte es möglich sein ihn, mit baugleichen, im Netzwrk zu erweitern.

Damit forderst du etwas was die Leistungsfähigkeit des Koordinators begrenzt.

WLan und Zigbee liegen im gleichen Frequenzband - daher ist ein Anschluss via LAN grenzwertig machbar, ein Anschluss über WLAN ist instabil. Koordinatoren sind dafür gemacht ein Netzwerk aufzubauen. Es ist Aufgabe aller fest am Strom verbundenen Geräte als Zigbee-Router zu agieren - das muss die Firmware sicherstellen. Nutzung von Koordinator-Hardware als Router ist wenig sinnvoll.

Eine genaue Empfehlung für einen LAN Koordinator gebe ich absichtlich nicht. Der Anschluss via Lan ist meiner Meinung nach nicht ideal, da darüber generell ein emuliertes serielles Protokoll gefahren wird ohne das sicherzustellen ist das eine serielle Nachricht auch in einem TCP Paket landet. (Wobei LAN besser ist als WLan, aber aus meiner Sicht immer noch nicht gut) Da das serielle Protokoll an der Stelle aber wenig Fehlertolerant ist können selbst kleine Auffälligkeiten im Netzwerk zu Problemen bei der seriellen Kommunikation führen.

Ich verweise an der Stelle auf die Kompatibilitätsliste bei Zigbee2mqtt.io. Dort werden verschiedene Koordinatoren (USB oder LAN) gelistet.

Die einzige Empfehlung die ich abgebe ist die Nutzung eines Koordinators basierend auf einem TI Chip.

A.