Ist die Last symetrisch auf allen 3 Phasen -> 1 Phasige Messung möglichst Berührungslos
Sind die Zustände in der Last definiert -> einfache Erfassung in IOBroker der Schaltzustände und zB Nutzung des virtuellen Stromzähler Adapters
Jeder technische Einbau auch Messinstrumente haben Fehlerpotential insbesondere wenn man es "billig" versucht. Warum also alles zwanghaft messen wenn das Ergebnis an 2 Fingern abzählbar ist und jede Messung auch Fehler hat.
Meine Empfehlung ist in dieser Leistungsklasse Abstand von den typischen SmartGeräten zu nehmen. Für den Dauerhaften Einsatz ist das alles nicht wirklich Vertrauenserweckend und Langlebig. Ebenso der Einsatz eines Schukosteckers suboptimal. Klarer Unterschied, du schaltest (fast) immer bei voller Leistung des Heißstabes Ein/Aus. Zb eine Waschmachine/Troker läuft erstmal im Programm an und belastet so den Schaltkontakt wesentlich weniger.
Klare Empfehlung einen kleinen Abzweigkasten zu verwenden z.B. 
dort dann entsprechend ein einpoliges Leistungsschütz zu verbauen zB:
Womit Du dieses dann schaltest ist recht egal. zB ein Shelly 1 Mini oder sowas geht prima.
Möchtest Du Stromverbrauch messen, dann klar die Empfehlung über Stromzange zB:
@bananajoe said in Frage zu Hausstromnetz und Zähler:
....
Auslesen wird mit so einem Hichi oder auch Volkszähler genannt gehen...
Nur Mal angemerkt, Volkszähler ist ein eigenes Projekt dass schon Jahrzehnte sich dem Thema Energie und Verbrauchsdatenmonitoring widmet. Der Lesekopf bzw. Die Schaltung wurde durch Udo entwickelt und lange Zeit zu sehr günstigen Konditionen auch privat verkauft. Da diese Entwicklung sehr gut funktioniert, hat sie sich enorm verbreitet. Originale von Udo werden keine mehr verkauft (die Schaltung gibt es kostenfrei auf der Homepage) und auch wenn mein Wissen dort lückenhaft ist, hat das wohl sehr persönliche Gründe. Fände es trotzdem angebracht Udo's Erbe und Leistung korrekt wert zu schätzen. Soll kein Vorwurf sein, aber bin Udo für seine frühen Leistungen in dem Bereich sehr Dankbar und der Lesekopf läuft bei mir seit Jahrzehnten ohne jegliche Probleme an vielen unterschiedlichen SW-Lösungen.
kannst Du machen. Es gibt Netzformen die dem sehr ähnlich sind. Die einzelnen Phasen/Kanäle sind komplett elektrisch unabhängig. Einzig bei speziellen Datenpunkten (Leistung aller Phasen) muß Du halt aufpassen, was noch stimmt und was nicht.
Just my 2 cent: Ich halte da recht wenig von. Ist Dein Zigbee Netz so Bulletproof inkl. der Heimautomatisierung? Ergänzend erwähnst Du selbst das Problem der unbeabsichtigten Betätigung was auch nix anderes wie Störungen sind. 2,3,4 Stück davon und "Laien" inkl. man selbst ist so verwirrt/genervt von diesen Fehlalarmen dass es für mich keinen Sinn macht.
Ich finde es beachtenswert, dass man die Liebsten nach bestem Wissen und Gewissen unterstützen möchte, aber dabei sollte man sehr mit Augenmaß aggieren.
Alternativ, wenn es nur um bestimmte räumliche Bereiche geht, kannst Du vielleicht auch mit Alexa etwas hilfreiches hinbekommen. Keywörter wie "Hilfe" lösen dann eine bestimmte Aktion aus. Wer möchte schon dauerhaft mit so einem "Halsband" rumlaufen. Und mal ein ganz praktischer/ehrlischer Fall: Nachts steht man auf zur Toilette. Wer nimmt das "Halsband" dann mit und wer stürzt dann öfters, da noch im Halbschlaf etc.? Will damit sagen (Mupheys Law), dass genau dann wenn es ernst wird so ein "Halsband" irgendwo unerreichbar liegt .... oder schlimmer sich jemand darauf verlässt und dann verlassen ist.
@jan1 said in Welcher Router:
@horst-böttcher
... dann bleibt nur noch mal ein Blick auf die benachbarten Funknetzte was da so rum schwirrt ....
Ergänzend zum Rest kann ich auch da nur zustimmen, wie Du deine Wohnsituation schilderst. Ich hab bei mir bei ~20 Netzen im 2,4GHz Band aufgehört zu zählen. Dazu kommt dann das Dir in der FritzBox nur Wlan angezeigt wird. Zigbee, Bluetooth etc etc muß man seperat scannen und dann übereinanderlegen ob es noch nutzbare Lücken gibt.
Aber ich kann den Ärger nachvollziehen und egal ob man nun mal auf dem Heimtrainer mit einem ANT+ Pulsgurt sitzt (sendet auch auf 2,4GHz) oder einfach nur mal ein Kopfhörerpaar über Bluetooth paired, irgendwo gibt es immer Probleme. Wenn voll dann voll da kann die FritzBox dann auch nix zu.
Bleibt nur Lücken suchen und weitesgehend auf 5GHz umsteigen wo es geht.
Du sprichst von Mesh-Verbindung des Repeaters. Wie sehen die Empfangswerte aus? Seitdem ich meine Repeater per Kabel mit dem Router verbunden hab und sie nur noch den Traffic zu den Clients über Wifi schicken sind alle Probleme verschwunden. Schwaches/Volles Wifi und dann noch ein Mesh Repeater über Wifi ist nicht optimal.
@dp20eic
Ein Gerät wie den E-Herd unbeaufsichtig also von extern oder automatisiert zu starten, halte ich eher für fahrlässig als sinnvoll und die Rückschlüsse über Nutzung und Verbrauch kann man wie erwähnt durch recht simple Erfassung des Verbrauchs generieren.
Die Nutzung von Zwischensteckern bei Hausgeräten dieser Leistungsklasse wäre allerdings nichts für mich und im schlimmsten Fall mit zu günstiger China-Hardware eher ein weiteres Sicherheitsrisiko. Entsprechend wäre mein Gedanke etwas Richtung Shelly 3EM also indirekt mittels Induktion zu nutzen, wenn überhaupt.
Kann mich noch gut erinnern und das Netz ist sicher noch voll davon, als 5x2,5mm² statt 5x1,5mm² für die E-Herd-Anschlussdose Pflicht wurde. Seitenweise Diskussionen wie gefährlich das doch alles ist und um nun 2023 hinzugehen und "pissilige" Chinarelais da zu nutzen, ist sicher kein sinnvolles Fazit oder eine Weiterentwicklung.
Da ich den E-Herd aber als notwendig und recht kurzzeitig betriebenes Gerät sehe, sehe ich da kaum Optimierungspotential insbesondere nicht ohne in Konflikt mit der Hausregierung zu geraten. Fazit: Finger weg und dafür Lecker etwas vorgesetzt bekommen 
@winni said in Steckdose gesucht:
@dieter_p nur eine schaltbar Steckdose mit Strommessung. Ich lade da mein E-Auto normalerweise mit PV-Überschuss. Im Moment mit einer TP-Link und 8 A, 10 oder 12A wären aber auch nicht schlecht. Die TP-Link möchte ich ersetzen der NOUS A1T traue ich so hohe Last auf Dauer auch nicht zu.
Mmmh, ich finde den Aufbau und den damit verbunden Verschleiß dieser Steckdosen durch das andauernde Ein/Austecken fast schlimmer/problematischer als die 12A überwiegend ohmische Last.
Ich hab selbst kein EAuto. Mit solch einer Dose
wo Du dann fest zB einen Shelly dazwischen baust, machst das aber einen stabileren Eindruck auf mich.
@tugsi said in Steckdose gesucht:
Für die von @Dieter_P vorgeschlagene blaue "Camping"-Steckdose müsste man dann ein anderes Ladegerät nehmen wie eine e-go oder Juice-Booster und die sind auch nicht mal eben günstig.
Sorry, NEIN. Der Ladeziegel mit Schukostecker ist dazu gedacht in eine 0815-Schukodose eingesteckt zu werden. Daran habe ich ein häufiges Ein/Ausstecken am Schukostecker als Schwachpunkt nahegelegt um dort nicht auch noch ergänzend mit einem Zwischenstecker (PV-Überschuss-Regelung) auf Schuko-basis weitere Schwachpunkte einzubauen.
Läst man nun stattdessen durch eine Fachkraft eine CEE 16A (blaue Dose) installieren mit einem zB Shelly davor (PV-Überschuss-Regelung), dann benötigt man lediglich einen solchen 5,99€ Adapter für sein Ladekabel/Ladeziegel. Selbstkontrolle natürlich vorausgesetzt, dass die Schokuverbindung möglichst dauerhaft bestehen bleibt. Warum dann eine neue Wallbox im Vergleich zur angefragten "Steckdosenempfehlung" notwendig ist, sehe ich nicht.
Aber bitte auch in Betracht ziehen, dass die 230V-Steckdose fest verbaut ist und sonst nichts anderes an der selben Leitung hängt. Denn sonst sind wir ganz schnell im Überlastbereich.
Heutzutage soll nach VDE für 16A 2,5qmm verlegt werden, früher war es noch 1,5qmm, dies wird aber mittlerweile nur noch mit 12A abgesichert.
Mags Du mir bitte die Passage in der DIN VDE100-430 zeigen? Leitungen mit 1,5mm² mit einem Stromführenden Leiter in üblicher Verlegeart (A,B1,B2,C) und bei 25°C Umgebungstemperatur dürfen weiterhin mit 16A abgesichert werden. Nutzt man dazu eine gangigen Automaten der Charakteristik B lässt dieser maximal einen Stromfluss von 16A für 45 Minuten zu bevor er auslöst.
Das klingt recht verwirrend was Du schilderst und ich verstehe daraus weder gesichert die aktuelle Situation noch was dein letzlicher Wunsch ist.
Ist an dem Stromstoßrelais nur nur ein Lastkontakt/Schließer belegt, dann kann man das mit einem Sonoff Mini realisieren oder zu mindest einem der auf Tasmota geflasht ist und entsprechend konfiguriert:
https://templates.blakadder.com/sonoff_MINIR4
Ob ich Dir das als Elektriker beruflich einbauen würde, steht auf einem anderen Papier und zu mindest ein Shelly 1 Pro macht da einen bestimmungsgemäßen Einbau offensichtlicher.
Und irgendeiner Deiner Komponenten (der Stromstoßschalter) oder die Hager Komponente daneben ist falschrum verbaut. Das ist schon mal ganz großer Murks! Wie soll ein Laie in einer Notsituation hier aggieren? Kopfstand machen damit er was lesen kann? 
Leidiges Thema insbesondere wenn man kostenintensive Hobbys auf 2 Rädern pflegt. Was da in diesen Hobbykreisen für Storys berichtet werden, ist schon nichtmehr zu ertragen.
Daher deponiere ich aus Prinzip nichts im Keller was mir etwas bedeutet. Ich mein, was soll eine "Alarmanlage" bewirken?
Bin ich nicht da, nix und ist wer da, geh ich dann in den Keller um mich mit diesen skrupelosen Intensivtätern zu kloppen und fang mir noch eine Anzeige wegen Körperverletzung nachdem sich da völlig überlastete Diensthabende zur Tatstelle begeben haben?
Für den Spieltrieb (sorry, subjektive Meinung), hast mal 433MHz probiert(zB RF Link:https://www.rflink.nl/)? Geht vielleicht eher durch die Wände.
Ansonsten eine Dicke Baustellenhupe am Bewegungsmelder die Du per Fernbedienung aktivieren/deaktivieren kannst. Davon nur wenige Fehlauslösungen und die Sache geht auch in die Tonne.
Hast Du Mobilfunkempfang im Keller? Es gibt schon recht günstige Alarmanlagen die sich dann über Mobilfunk melden. Was der Tarif dazu kostet natürlich interessant.
Und ich wäre nicht überrascht wenn zur Standardausrüstung der bösen Buben mitlerweile irgendwelche FunkJammer gehören die mal alles in der Umgebung "plätten".
Hallo Simon
ja wir sprechen über eine Beta Version von github, darf ich dennoch fragen ob eine Installation derzeit nach Deinem Verständnis für einen einfachen Nutzer funktionieren sollte? Der Kommunikation der Entwickler (https://github.com/DrozmotiX/ioBroker.esphome/pull/183) kann man folgen, aber heißt nicht dass man es auch versteht 
Ich möchte auf einem system ESPHome temporär für einen Test nutzen, aber kann dieses System nicht so einfach neu aufsetzen. Es ähnelt für mich stark dem System von @Fischje
wie folgt:
Debian 12 Bookworm, kein Docker.
Dashboard esphome : 0.5.0-beta.10
Admin-Adapter: 7.1.5
Python: 3.11.2
node: v20.18.1
das Ganze erzeugt den Fehler:
esphome.0
2024-11-21 08:48:09.852 error Fatal error starting ESPHomeDashboard | Error: Command failed with exit code 1: /home/iobroker/.cache/autopy/venv/esphome/bin/python3 -m pip install esphome==2024.11.0 pillow==10.0.1ERROR: Cannot install esphome==2024.11.0 and pillow==10.0.1 because these package versions have conflicting dependencies.ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts[notice] A new release of pip is available: 24.0 -> 24.3.1[notice] To update, run: /home/iobroker/.cache/autopy/venv/esphome/bin/python3 -m pip install --upgrade pipCollecting esphome==2024.11.0 Using cached esphome-2024.11.0-py3-none-any.whl.metadata (3.5 kB)Collecting pillow==10.0.1 Using cached Pillow-10.0.1-cp311-cp311-manylinux_2_28_x86_64.whl.metadata (9.5 kB)Collecting cryptography==43.0.0 (from esphome==2024.11.0) Using cached cryptography-43.0.0-cp39-abi3-manylinux_2_28_x86_64.whl.metadata (5.4 kB)Collecting voluptuous==0.14.2 (from esphome==2024.11.0) Using cached voluptuous-0.14.2-py3-none-any.whl.metadata (20 kB)Collecting PyYAML==6.0.2 (from esphome==2024.11.0) Using cached PyYAML-6.0.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.1 kB)Collecting paho-mqtt==1.6.1 (from esphome==2024.11.0) Using cached paho-mqtt-1.6.1.tar.gz (99 kB) Installing build dependencies: started Installing build dependencies: finished with status 'done' Getting requirements to build wheel: started Getting requirements to build wheel: finished with status 'done' Preparing metadata (pyproject.toml): started Preparing metadata (pyproject.toml): finished with status 'done'Collecting colorama==0.4.6 (from esphome==2024.11.0) Using cached colorama-0.4.6-py2.py3-none-any.whl.metadata (17 kB)Collecting icmplib==3.0.4 (from esphome==2024.11.0) Using cached icmplib-3.0.4-py3-none-any.whl.metadata (19 kB)Collecting tornado==6.4 (from esphome==2024.11.0) Using cached tornado-6.4-cp38-abi3-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.5 kB)Collecting tzlocal==5.2 (from esphome==2024.11.0) Using cached tzlocal-5.2-py3-none-any.whl.metadata (7.8 kB)Collecting tzdata>=2021.1 (from esphome==2024.11.0) Using cached tzdata-2024.2-py2.py3-none-any.whl.metadata (1.4 kB)Collecting pyserial==3.5 (from esphome==2024.11.0) Using cached pyserial-3.5-py2.py3-none-any.whl.metadata (1.6 kB)Collecting platformio==6.1.16 (from esphome==2024.11.0) Using cached platformio-6.1.16.tar.gz (239 kB) Installing build dependencies: started Installing build dependencies: finished with status 'done' Getting requirements to build wheel: started Getting requirements to build wheel: finished with status 'done' Preparing metadata (pyproject.toml): started Preparing metadata (pyproject.toml): finished with status 'done'Collecting esptool==4.7.0 (from esphome==2024.11.0) Using cached esptool-4.7.0.tar.gz (285 kB) Installing build dependencies: started Installing build dependencies: finished with status 'done' Getting requirements to build wheel: started Getting requirements to build wheel: finished with status 'done' Preparing metadata (pyproject.toml): started Preparing metadata (pyproject.toml): finished with status 'done'Collecting click==8.1.7 (from esphome==2024.11.0) Using cached click-8.1.7-py3-none-any.whl.metadata (3.0 kB)Collecting esphome-dashboard==20241120.0 (from esphome==2024.11.0) Using cached esphome_dashboard-20241120.0-py3-none-any.whl.metadata (1.0 kB)Collecting aioesphomeapi==24.6.2 (from esphome==2024.11.0) Using cached aioesphomeapi-24.6.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (4.9 kB)Collecting zeroconf==0.132.2 (from esphome==2024.11.0) Using cached zeroconf-0.132.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (6.0 kB)Collecting puremagic==1.27 (from esphome==2024.11.0) Using cached puremagic-1.27-py3-none-any.whl.metadata (5.8 kB)Collecting ruamel.yaml==0.18.6 (from esphome==2024.11.0) Using cached ruamel.yaml-0.18.6-py3-none-any.whl.metadata (23 kB)Collecting glyphsets==1.0.0 (from esphome==2024.11.0) Using cached glyphsets-1.0.0-py3-none-any.whl.metadata (12 kB)INFO: pip is looking at multiple versions of esphome to determine which version is compatible with other requirements. This could take a while.The conflict is caused by: The user requested pillow==10.0.1 esphome 2024.11.0 depends on pillow==10.4.0To fix this you could try to:1. loosen the range of package versions you've specified2. remove package versions to allow pip attempt to solve the dependency conflict | Error: Command failed with exit code 1: /home/iobroker/.cache/autopy/venv/esphome/bin/python3 -m pip install esphome==2024.11.0 pillow==10.0.1ERROR: Cannot install esphome==2024.11.0 and pillow==10.0.1 because these package versions have conflicting dependencies.ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts[notice] A new release of pip is available: 24.0 -> 24.3.1[notice] To update, run: /home/iobroker/.cache/autopy/venv/esphome/bin/python3 -m pip install --upgrade pipCollecting esphome==2024.11.0 Using cached esphome-2024.11.0-py3-none-any.whl.metadata (3.5 kB)Collecting pillow==10.0.1 Using cached Pillow-10.0.1-cp311-cp311-manylinux_2_28_x86_64.whl.metadata (9.5 kB)Collecting cryptography==43.0.0 (from esphome==2024.11.0) Using cached cryptography-43.0.0-cp39-abi3-manylinux_2_28_x86_64.whl.metadata (5.4 kB)Collecting voluptuous==0.14.2 (from esphome==2024.11.0) Using cached voluptuous-0.14.2-py3-none-any.whl.metadata (20 kB)Collecting PyYAML==6.0.2 (from esphome==2024.11.0) Using cached PyYAML-6.0.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.1 kB)Collecting paho-mqtt==1.6.1 (from esphome==2024.11.0) Using cached paho-mqtt-1.6.1.tar.gz (99 kB) Installing build dependencies: started Installing build dependencies: finished with status 'done' Getting requirements to build wheel: started Getting requirements to build wheel: finished with status 'done' Preparing metadata (pyproject.toml): started Preparing metadata (pyproject.toml): finished with status 'done'Collecting colorama==0.4.6 (from esphome==2024.11.0) Using cached colorama-0.4.6-py2.py3-none-any.whl.metadata (17 kB)Collecting icmplib==3.0.4 (from esphome==2024.11.0) Using cached icmplib-3.0.4-py3-none-any.whl.metadata (19 kB)Collecting tornado==6.4 (from esphome==2024.11.0) Using cached tornado-6.4-cp38-abi3-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.5 kB)Collecting tzlocal==5.2 (from esphome==2024.11.0) Using cached tzlocal-5.2-py3-none-any.whl.metadata (7.8 kB)Collecting tzdata>=2021.1 (from esphome==2024.11.0) Using cached tzdata-2024.2-py2.py3-none-any.whl.metadata (1.4 kB)Collecting pyserial==3.5 (from esphome==2024.11.0) Using cached pyserial-3.5-py2.py3-none-any.whl.metadata (1.6 kB)Collecting platformio==6.1.16 (from esphome==2024.11.0) Using cached platformio-6.1.16.tar.gz (239 kB) Installing build dependencies: started Installing build dependencies: finished with status 'done' Getting requirements to build wheel: started Getting requirements to build wheel: finished with status 'done' Preparing metadata (pyproject.toml): started Preparing metadata (pyproject.toml): finished with status 'done'Collecting esptool==4.7.0 (from esphome==2024.11.0) Using cached esptool-4.7.0.tar.gz (285 kB) Installing build dependencies: started Installing build dependencies: finished with status 'done' Getting requirements to build wheel: started Getting requirements to build wheel: finished with status 'done' Preparing metadata (pyproject.toml): started Preparing metadata (pyproject.toml): finished with status 'done'Collecting click==8.1.7 (from esphome==2024.11.0) Using cached click-8.1.7-py3-none-any.whl.metadata (3.0 kB)Collecting esphome-dashboard==20241120.0 (from esphome==2024.11.0) Using cached esphome_dashboard-20241120.0-py3-none-any.whl.metadata (1.0 kB)Collecting aioesphomeapi==24.6.2 (from esphome==2024.11.0) Using cached aioesphomeapi-24.6.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (4.9 kB)Collecting zeroconf==0.132.2 (from esphome==2024.11.0) Using cached zeroconf-0.132.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (6.0 kB)Collecting puremagic==1.27 (from esphome==2024.11.0) Using cached puremagic-1.27-py3-none-any.whl.metadata (5.8 kB)Collecting ruamel.yaml==0.18.6 (from esphome==2024.11.0) Using cached ruamel.yaml-0.18.6-py3-none-any.whl.metadata (23 kB)Collecting glyphsets==1.0.0 (from esphome==2024.11.0) Using cached glyphsets-1.0.0-py3-none-any.whl.metadata (12 kB)INFO: pip is looking at multiple versions of esphome to determine which version is compatible with other requirements. This could take a while.The conflict is caused by: The user requested pillow==10.0.1 esphome 2024.11.0 depends on pillow==10.4.0To fix this you could try to:1. loosen the range of package versions you've specified2. remove package versions to allow pip attempt to solve the dependency conflict at makeError (file:///opt/iobroker/node_modules/autopy/node_modules/execa/lib/error.js:60:11) at handlePromise (file:///opt/iobroker/node_modules/autopy/node_modules/execa/index.js:124:26) at processTicksAndRejections (node:internal/process/task_queues:95:5) at $df9eabe9bda49ea8$export$e522f41234ab669a (file:///opt/iobroker/node_modules/autopy/src/index.ts:257:13) at Esphome.espHomeDashboard (/Users/nl69zh/Developer/community/opensource/ioBroker.esphome/main.js:180:7) at Esphome.onReady (/opt/iobroker/node_modules/iobroker.esphome/main.js:66:4)
Da ich noch ein system hab wo ESPHome auch im produktiven Einsatz ist, hatte ich mir dort python3 in version 3.9.2 abgeschaut und mit pyenv probiert aber bringt keinen Erfolg.
Kannst Du sagen welchen Status das Ganze hat und ich vielleicht besser die Versuche einstellen sollte?
Danke
jetzt wirds spooky. Wollte mal testen und hab eine Dose wieder auf v14.3.07 gezogen und wollte sie mal mit dem Mosquitto Broker verbinden um zu sehen was passiert. Aber selbst am IOBroker-Mqtt-Broker ist nun Ruhe in den Logs obwohl ich im Tasmota Log schön alle publish command sehe die bisher die Fehler produziert haben....
bzgl. mqtt version bin ich auf github nicht schlauer geworden zum iobroker adapter.
Interessant:
Da ich bis auf Tasmota Version zum Relayboard keinen Unterschied gesehen hab, hab ich eine Steckdose auf den aktuellsten Status also v14.3.0.7 upgedated
und die andere Dose runter auf v13.4
Dann publish und Ergebnis, es erscheinen nur noch Fehler der v14.3 er Dose im Log
mqtt.0
2024-11-20 12:12:40.196 error Client [DVES_29BD00] Cannot parse "stat/tasmota_29BD00/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B2266616E223A317D [{"fan":1}]"}
mqtt.0
2024-11-20 12:12:20.129 error Client [DVES_29BD00] Cannot parse "stat/tasmota_29BD00/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B2266616E223A317D [{"fan":1}]"}
mqtt.0
2024-11-20 12:12:00.119 error Client [DVES_29BD00] Cannot parse "stat/tasmota_29BD00/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B2266616E223A317D [{"fan":1}]"}
na supi
Edit: nun beide Dosen auf 13.4 und Ruhe ist. Ob das so sein soll(v14), darf man ja bezweifeln.
@bananajoe said in MQTT Error von Tasmota Publish/Suscription Einstellung?:
Nimm den Haken mal raus, das brauchen die Clients nicht. Das könnte das Problem sein.
Bisher leider nein. Nach dem Neustart des mqtt0 und dann Ausführung des Publish wieder die Meldung.
Hätte mich auch ehrlicherweise gewundert. Für mich ist das eine Reaktion von Tasmota Geräten zu Publish Befehlen, die sie "nix angehen".
Aber warte mal. Mir fällt gerade auf dass sich nur 2 Tasmota Geräte im IOBroker Log dazu melden. Ich habe aber mehr mit MQTT eingebunden.
Ich schau mal ob es da einen Unterschied gibt.
Edit:
Erster großer Unterschied, viele Tasmota Geräte hab ich gar nicht für Mqtt konfiguriert 
da kann sich nix melden.
Hab nur noch 1 Relayboards gefunden mit MQTT Konfiguration das läuft auf Tasmota v13.4 und die "meckernden" Steckdosen auf v14.03.01. Sonst sehe ich keinen Unterschied.
@bananajoe said in MQTT Error von Tasmota Publish/Suscription Einstellung?:
Das herumreiten auf den Mosquitto kommt nur daher das der ja schon da ist und du ihn scheinbar nur für eine Sache nutzt.
Kein Ding und bei dem "Konstrukt" bin ich ja überrascht, dass es nicht schon vorher kommentiert wurde und empfinde es selbst als gewachsene Notlösung.
Eigentlich war ich mit einer MqTT Broker/Client Instanz sehr zufrieden und das sollte auch so bleiben. Hab auch nicht das Gefühl Unmengen an Geräten darüber zu fahren.
Dann ging der "Spaß" los und das letzte neu installierte Gerät (openHASP Touch Panel) verträgt sich nicht mit dem IOBroker mqtt Broker: https://forum.iobroker.net/topic/76093/fehler-mit-mqtt-adapter-forbidden-properties/24?_=1732084848179
Zum Glück funktioniert der mqtt-client damit. Also kam dafür Mosquitto dazu.
Dann nutze ich zum publishen die MQTT-Blocklys und hier lassen sich nur Instanzen des MQTT-Broker-Adapters auswählen. Somit bin ich dann bei der zweiten Instanz mqtt1 des Broker/Clients.
Ich habe noch einen letzten Funken Hoffnung, dass die Entwickler des Mqtt Broker-Adapters sich dem gemeldeten annehmen und würde dann zurück bauen auf wieder eine Instanz und Broker.
Den Gedanken bzgl. nur einen Broker aber dann Mosquitto muß ich mal durch den Kopf gehen lassen. Problem, dass ich nicht auf der Kommandozeile geboren wurde und Mosquitto komplett darüber zu konfigurieren ist. Ergänzend ist mir noch nicht geglückt eine für mich verständliche heißt Nicht-Skript-Lösung also Blockly zum publishen ohne die spezifischen Blöcke zu realisieren.
Nichtsdestotrotz genau wie du sagst, ist mir aber prinzipiell beim Thema der Fehlermeldung nicht verständlich warum wieso dort von Tasmota etwas kommt. Für sollten die publish Befehle von Tasmota ignoriert werden und hier wie gezeigt gibt es scheinbar unterschiede in den cmds die ich publishe.
@bananajoe ok, einmal Bilderbuch
Einmal der zentrale mqtt0 Broker:
Dann der mqtt-client (Verbindung zum Mosquitto Broker) (Daten Empfangen vom Touch Panel):
Dann noch ein Client per broker/client Adapter mqtt.1 um die mqtt-Blocklys zum publishen nutzen zu können:
Ich publish auch zyklisch eine Raumtemperatur an die Reglung:
Tasmota bekommt auch das mit:
12:11:59.790 MQT: stat/tasmota_C1B666/RESULT = {"Command":"Unknown","Input":"CONTROL {\"env\":20.2}"}
Darüber hab ich komischerweise keinen Error-Eintrag im IObroker/Mqtt-Broker Log
Über die Sollwertänderung gibt es folgenden Tasmota Log:
12:20:00.416 MQT: stat/tasmota_C1B666/RESULT = {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32337D [{"autot":23}]"}
und promt wieder Error im IObroker:
mqtt.0
2024-11-19 12:20:36.761 error Client [DVES_C1B666] Cannot parse "stat/tasmota_C1B666/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32327D [{"autot":22}]"}
mqtt.0
2024-11-19 12:20:36.741 error Client [DVES_29BD00] Cannot parse "stat/tasmota_29BD00/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32327D [{"autot":22}]"}
mqtt.0
2024-11-19 12:20:34.483 error Client [DVES_29BD00] Cannot parse "stat/tasmota_29BD00/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32312E357D [{"autot":21.5}]"}
mqtt.0
2024-11-19 12:20:34.456 error Client [DVES_C1B666] Cannot parse "stat/tasmota_C1B666/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32312E357D [{"autot":21.5}]"}
mqtt.0
2024-11-19 12:20:33.656 error Client [DVES_C1B666] Cannot parse "stat/tasmota_C1B666/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32327D [{"autot":22}]"}
mqtt.0
2024-11-19 12:20:33.629 error Client [DVES_29BD00] Cannot parse "stat/tasmota_29BD00/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32327D [{"autot":22}]"}
mqtt.0
2024-11-19 12:20:30.019 error Client [DVES_29BD00] Cannot parse "stat/tasmota_29BD00/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32322E357D [{"autot":22.5}]"}
mqtt.0
2024-11-19 12:20:29.999 error Client [DVES_C1B666] Cannot parse "stat/tasmota_C1B666/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32322E357D [{"autot":22.5}]"}
mqtt.0
2024-11-19 12:20:29.364 error Client [DVES_29BD00] Cannot parse "stat/tasmota_29BD00/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32322E357D [{"autot":22.5}]"}
mqtt.0
2024-11-19 12:20:29.360 error Client [DVES_C1B666] Cannot parse "stat/tasmota_C1B666/RESULT": {"Command":"Unknown","Input":"F0F5BD731830 7B226175746F74223A32322E357D [{"autot":22.5}]"}
@bananajoe said in MQTT Error von Tasmota Publish/Suscription Einstellung?:
kannst mal ein wenig genauer zeigen wie und was du das published?
Das ist blockly wie ich zum Hezungsregler publish.
Was für einen MQTT-Broker nutzt du?
der mqtt0 ist der IOBroker Adapter als Broker und dort hängt der Heizungsregler.
Es gibt noch einen weiteren Mosquitto Broker. Dort hängt das Touch Panel dran, da OpenHasp nur mit dem mqtt-client Adapter von IOBroker funktioniert. Beide Broker werden über unterschiedliche Ports verbunden. Ist natürlich ein Konstrukt aber da ich nur an mqtt0 hier publishe wo auch alle sonstigen Geräte wie Tasmota hängen, sehe ich das nicht als beachtenswert.
Danke 2 Tage an so was rumbasteln lassen gerade wohl den Wald vor Bäumen nicht erkennen.
Hab da jetzt irgendeine Lösung im IOBroker mit 2 DPs im Kopf gehabt die sich irgendwie synchronisieren und am Ende dann auch wieder Fehlerquelle sein können.
Aber klar, publishen gleichzeitig zum Regler und zurück zum Display.
Eine Verriegelung des 2ten Triggers muß ich mal gucken, wie das klappen kann.
