nächste Frage: Kann ich die DTU oder shelly im AP mode lassen? Ich hätte die Regelung gern ohne Kontakt nach aussen, oder ist das übervorsichtig?
Unter den Netzwerkeinstellungen der OpenDTU deine WLAN Daten eintragen und im Router anschließend am besten eine feste IP Adresse zuweisen. Läuft dann alles Lokal, oder was meinst du genau. Vom Shelly hab ich leider kein Plan.
AP= Access Point?
hab überlegt wenn die dtu im ap mode bleiben kann dass ich shelly ohne kontakt nach aussen mit der dtu reden lasse.
ist aber wahrscheinlich keine gute idee, falls ich es doch noch schaffe, netzdaten von meinem versorger zu bekommen muss da eh kommunikation passieren nach aussen
Ehhh, bist du dir sicher das dein Plan fünktioniert:
“1. shelly EM50 zum laufen bringen. Installiert, leuchtet rot und blau. Soll nur mit opendtu reden”
Kenne eigentlich nur die Zusammenarbeit mit einem Shelly Pro 3EM
Gruß
nett dass du das nicht kennst. hilft mir grad überhaupt nicht weiter.
scheinbar kann man den shelly kram gar nicht lokal einrichten, alles der gleiche dreck wie bei tuya mit cloud dings. nur dass hier auch noch die app ultra grottig ist ich versuch schon ne stunde mich mim zähler zu verbinden
1 „Gefällt mir“
Also soweit ich lese sollte das doch genauso wie mit der OpenDTU funzen.
Einfach über den Access Point einloggen, dann unter den "Netzwerkeinstellungen" die Daten von deinem WLAN rein, und feste IP Adresse im Router vergeben. Wo klemmts denn genau? Kommst du nicht auf den Shelly über den Access Point? Geräte die nicht Offline und/oder ohne Cloud laufen landen bei mir in der Mülltonne bzw. werden garnicht erst gekauft.
Im AP mode war der shelly nicht erreichbar. Jedenfalls scheint der jetzt ins Internet zu funken und am Tele kann ich mir die Leistung ansehen.
OK lokal am Rechner auch. MQTT settings passt des?
ich muss bei server was reinschreiben. sonst gehts nicht weiter
Wie bist du denn da drauf gekommen wenn nicht erstmal über den Access Point?
Du must doch erstmal über den Access Point drauf... das Ding muss doch erstmal im WLAN sichtbar sein. Mit dem MQTT Zeug kenn ich mich leider garnicht aus, sorry 
.
gefühlt 2 stunden mit der grottigen app. die hängt sich gern mal weg. wenns endlich läuft verbindet die sich mit ble oder über den ap. funktioniert irgendwann nach paar versuchen. irgendwo mittendrin hängt sich der shelly 2 mal für paar minuten weg weil der sich updates zieht und installiert oder sowas. beim einrichten macht der auch paar neustarts. isn esp8266 drin also gleich wie tuya
1 „Gefällt mir“
Schalt doch das Cloud Gedöns in den Einstellungen Aus, das sollte gehen soweit ich gelesen habe. Dann kann das Ding schonmal nicht mehr "nach Hause Telefonieren". Wenn allerdings die Verbindung über App so grottig ist würde ich die Kriese kriegen... aber ich mag auch generell das ganze App Zeug im Grunde nicht. Über Browser sollte es weitaus besser und stabiler laufen 
. Feste IP Adresse im Router, dann über den Browser und du hast Ruhe mit den ganzen Verbindungsstörungen, zumindest sofern das Ding ansich was taugt .
jajein. wenn der kram endlich läuft kann ich cloud ausmachen. die lokale oberfläche am rechner liefert zahlen, die cloud app kann auch z.B. Verbrauch grafisch darstellen über tag, woche usw
aktuell offene Punkte:
- Einstellungen MQTT auf dtu und shelly dass die miteinander können
- irgendwas mit pinmapping was beim bin aufspielen verloren gegangen ist und wieder eingetragen werden muss. Dann laufen display und der NRF wieder
Zu 2.
Jup, ich hab bei mir ne spezielle PinMapping Datei extra für das Display weil die Belegung anders ist auf meiner OpenDTU Platine als die Standard Belegung.
Die must du hier (kann sein das die Menü Struktur bei dir etwas anders aussieht) hochladen und dann neustarten:
Vorher Pin Mapping auswählen...
Dann noch hier auswählen welches Display du hast:
Hier stehts auch nochmal:
https: //opendtu-onbattery.net/firmware/device_profiles/
Zu 1, Einstellungen MQTT auf dtu und shelly dass die miteinander können
MQTT brauchst du bei dir nicht, sondern nur wenn du irgendwelche Daten vom Shelly oder der DTU für ein zusätzliches, extra vorhandenes übergeordnetes System (iobroker oder homeautomation o.ä.) brauchst. Also beim Shelly den Haken weg machen. Noch wichtig Shelly und DTU müssen im gleichen WLAN Netz sein.
Hab mir diese Datei aufm Rechner gespeichert
ist das überhaupt die richtige? 265kB? massig skripte die ich noch nich durchblicke, hunderte referenzen auf externes incl amazon, microsoft, copilot und weissnichwas aber beim durchschauen sehe ich da kein pin mapping (oder ich habs überlesen)
ich frage den shelly ab mit http : // shellyproem50-xxxxxxxxx.local/rpc/Shelly.GetStatus. Die antwort im browser ist:
{"ble":{},"bthome":{"errors":["bluetooth_disabled"]},"cloud":{"connected":true},"em1:0":{"id":0,"current":0.327,"voltage":233.0,"act_power":-8.2,"aprt_power":76.4,"pf":0.53,"freq":50.0,"calibration":"factory"},"em1:1":{"id":1,"current":0.020,"voltage":233.0,"act_power":0.0,"aprt_power":4.7,"pf":0.00,"freq":50.0,"calibration":"factory"},"em1data:0":{"id":0,"total_act_energy":257.60,"total_act_ret_energy":189.21},"em1data:1":{"id":1,"total_act_energy":0.01,"total_act_ret_energy":0.00},"eth":{"ip":null}
Ich hab http/json als Übertragung gewählt. in der openDTU eingegeben
URL: http : // shellyproem50-xxxxxxxxx.local/rpc/Shelly.GetStatus
JSON-Pfad aus der browserantwort rausgefummelt: em1:0/act_power Verbrauch Wohnung, 2. Wert aktiviert em1:1/act_power mein Boiler. Unten test geklickt und …
ich glaub des funzt
Die oberen 2 Dateien hättest du sichern müssen (gelber Kreis), Wiederherstellen nacheinander im orangen Kreis. Ev reicht schon deine Ahoy Pinout Datei von oben.
Ansonsten kann ich nur wärmstens empfehlen in der Doku nachschlagen Device Profiles - OpenDTU-OnBattery Documentation , oder dort https://allianceapps.io/ das für 45€ ist fix und fertig mit Software, sofort einsatzbereit (nur noch Shelly verbinden, WR eintragen und Wlan) oder das 30€ Teil musst dann selbst Hand anlegen. Großer Vorteil, hat den neuesten Chip mit 16MB und brauchst bei Updates alles nur noch über Wlan machen.
Dabei fällt mir ein, wieviel MB hat eigentlich dein ESP32? Habe noch dunkel in Erinnerung, das die neuere DTU bei zu wenig Speicher nicht richtig läuft (min 4 oder 8MB ??), deshalb beim Fertigteil die 16MB Variante auch für die Zukunft.
immerhin reden dtu und em50 schon mal miteinander. Dass ich die hätte speichern müssen kommt zu spät. muss ich diese riesendatei oben (265k!) umbenennen, editieren, oder mir da nen schnipsel rauskopiern? - hatte mal gedacht um stromzähler mim wr zu verbinden brauchts nit viel, paar kB quellcode vielleicht, aber des ist alles so riesig
alte 4MB liegt schon 1 Jahr hier, das heißt ich muss updates am usb machen und nicht ota. es ist ja “extra” ne 4MB softwareversion
Nochmal dringende Nachfrage, nutzt du einen EM50 oder einen Shelly Pro3EM, oder ev beide?
Habe es bei mir noch mal nachgesehen (P3EM) sieht so aus, der EM50 könnte ähnlich eingetragen werden, IP anpassen, bei Stromzähler Einstellungen
Die Sicherungsdateien sind zusammen 20kB 
hab ich doch genau geschrieben pro em50. läuft. siehe weiter oben. fun fact: besser die json antwort im browser anschauen und danach das json schreiben. scheint mehrere versionen der antwort zu geben
beim pin mapping hab ich noch ne denksperre
GitHub - markusdd/OpenDTUFusionDocs: OpenDTU Fusion Documentation Repository · GitHub weit unten, ist für das Fertig Board
ansonsten , wenn angezeigt rechts oben Pfeil anwählen und verschiedene Varianten ausprobieren, hab ich auch so gemacht, bis es geklappt hat 
ich lauf schon wieder auf. Aus mehreren Quellen mir ein pin mapping zamgebaut was passen müßte, aber es kommt immer der Fehler “json falsch formatierrt”. Was ist verkehrt?
[
{
"name": "AhoyDTU ESP32 Display LED",
"nrf24": {
"miso": 19,
"mosi": 23,
"clk": 18,
"irq": 16,
"en": 4,
"cs": 5
},
"cmt": {
"clk": 12,
"cs": 27,
"fcs": 26,
"sdio": 14,
"gpio2": -1,
"gpio3": -1
},
"eth": {
"enabled": false,
"phy_addr": 0,
"power": -1,
"mdc": 23,
"mdio": 18,
"type": 0,
"clk_mode": 0
},
"display": {
"type": 2,
"data": 21,
"clk": 22,
"reset": 255
}
"led": {
"led0": 15,
"led1": 2
}
}
]