Beiträge von TirCendelius

    Danke, werde ich ausprobieren.

    ....

    Ich lass es nun bleiben und schau in X Monaten wieder ob es neue oder andere Lösungen gibt. ...

    Habe den ESP01 gegen einen ESP32-C3 ersetzt und die Spezialversion aufgespielt... hat Daten geliefert und ziemlich beeindruckend mit den Diagrammen, aber das Marstek B2500 Ding wollte einfach nicht den Sensor finden.

    Da ständig auch ein Rapberry Pi läuft, habe ich darauf kurzerhand den "Uni-Meter" installiert der die Daten vom Tasmotasensor abgreift. Auch das wollte nicht so recht funktionieren. Letztlich hat nur der Modus als Ecotracker funktioniert und selbst das brauchte mehrfach Anläufe. Man zweifelt an seinem Verstand, wenn einfach nichts hinhaut. Wie dem auch sei, ende gut, alles gut.

    GitHub - sdeigm/uni-meter: A universal electric meter data converter (emulator)
    A universal electric meter data converter (emulator) - sdeigm/uni-meter
    github.com

    Danke, werde ich ausprobieren.

    bei diesem IP/V1/JSON werden die Daten korrekt angezeigt. Die Batteriespeicher-App findet trotzdem nichts. :D

    Das Thema hier ist hoch chaotisch mit den ganzen Code Schnippsel wo man als dritter gar nicht weiß, was geht, was braucht man und selbst wenn man erahnt, was gebraucht wird, landet man in einer Sackgasse. Ich nutze den Tasmo-Compiler... offenbar braucht man in diesem Spezialfall aber dieses PlatformIO das mir viel zu überladen und unübersichtlich ist.

    Ich lass es nun bleiben und schau in X Monaten wieder ob es neue oder andere Lösungen gibt. Dieses Solarzeug hat einen haufen Geld gekostet... da würden 70 Euro für so ein Shelly Pro 3EM auch nicht mehr groß ins Gewicht fallen. Mal schauen...


    Unter der URL ip/v1/json erhalte ich nur ein "Datei nicht gefunden"


    Mit dem Tasmo-Compiler verwende ich diese Einstellungen. Braucht es da noch weitere Parameter?

    #define USE_SCRIPT
    #define USE_SML_M
    #ifdef USE_RULES
    #undef USE_RULES
    #endif
    #define USE_DS18x20 // Add support for DS18x20 sensors with id sort, single scan and read retry (+2k6 code)

    #define USE_SCRIPT_GLOBVARS


    Google Gemini meint das noch #define USE_UDP mit dazu muss, ändert aber sonst nichts.


    Braucht das Programm da zwingend die ESP32 Version? Mein IR Leser ist auf einem ESP8266-01S


    Gemini meint weiter das noch

    #ifndef USE_SCRIPT_WEB_SERVER #define USE_SCRIPT_WEB_SERVER // Erlaubt dem Skript, seinen eigenen Webserver zu betreiben/an HTTP-Anfragen zu lauschen #endif

    und

    #ifndef USE_WEBSEND #define USE_WEBSEND // Stellt sicher, dass die WebSend-Funktion verfügbar ist #endif


    dazu sollte.... bringt auch nichts. Weiter schlägt Gemini vor, ein WON Test zu probieren, der auch nicht geht.

    Die Sensorwerte vom Stromzähler werden korrekt angezeigt, aber nur in der normalen Tasmota Ansicht bzw. im MQTT

    >D 0

    >ah

    won(1 "/test")


    >on1

    print My test handler was called!

    WebSend HTTP/1.1 200 OK\r\nContent-type: text/plain\r\n\r\nHello from Tasmota script!\r\n


    Mit der Tasmota Vorcompilierte Version von dort https://drive.google.com/drive/folders/…UGG3A1-oLO14g5z werd nun unter v1/json etwas angezeigt. Die Marstek-App erkennt nichts... weder mit den drei Shelly Varianten noch mit diesem EcoTracker.

    Ich lass es gut sein... heute genug Zeit verschwendet.


    Hab noch den Uni-meter ausprobiert... ich meine in der Config alles richtig eingegeben zu haben, aber wird trotzdem nichts angezeigt. Diese Open-Source Projekte sind hochgradig frustrierend.

    433 Bridge

    Code
    19:03:02.388 CMD: SetOption28
    19:03:02.394 MQT: stat/tasmota_rf433_C37FA9/RESULT = {"SetOption28":"OFF"}
    19:04:18.462 MQT: tele/tasmota_rf433_C37FA9/RESULT = {"Time":"2025-01-31T19:04:18","RfReceived":{"Sync":11230,"Low":330,"High":1050,"Data":"FF5F78","RfKey":"None"}}
    19:05:34.978 MQT: tele/tasmota_rf433_C37FA9/RESULT = {"Time":"2025-01-31T19:05:34","RfReceived":{"Sync":11190,"Low":320,"High":1050,"Data":"FF5F72","RfKey":"None"}}
    19:07:16.771 MQT: stat/tasmota_rf433_C37FA9/RESULT = {"SetOption28":"ON"}
    19:07:19.255 MQT: tele/tasmota_rf433_C37FA9/RESULT = {"Time":"2025-01-31T19:07:19","RfReceived":{"Sync":11190,"Low":340,"High":1060,"Data":16736114,"RfKey":"None"}}


    Katze

    Code
    19:03:09.036 CMD: SetOption28
    19:03:09.041 MQT: stat/tasmota_61FEE0/RESULT = {"SetOption28":"OFF"}
    19:04:11.207 CMD: SetOption28 1
    19:04:11.212 MQT: stat/tasmota_61FEE0/RESULT = {"SetOption28":"ON"}
    19:04:17.851 MQT: tele/tasmota_61FEE0/RESULT = {"Time":"2025-01-31T19:04:17","RfReceived":{"Data":16736120,"Bits":24,"Protocol":1,"Pulse":362}}
    19:05:31.162 CMD: SetOption28 0
    19:05:31.167 MQT: stat/tasmota_61FEE0/RESULT = {"SetOption28":"OFF"}
    19:05:34.372 MQT: tele/tasmota_61FEE0/RESULT = {"Time":"2025-01-31T19:05:34","RfReceived":{"Data":"0xFF5F72","Bits":24,"Protocol":1,"Pulse":360}}

    Diese Option war bei beiden bereits auf 0

    Beide auf Dezimal Format stellen, vereinheitlicht die Ausgabe. Ich denke das ist als Lösung akzeptabel. Macht halt Arbeit, beim IOBroker die Scripte von Hex zu Dec umzuändern.


    Besten Dank :)

    433 Bridge

    23:34:11.459 MQT: tele/tasmota_rf433_C37FA9/RESULT = {"Time":"2025-01-30T23:34:11","RfReceived":{"Sync":11190,"Low":340,"High":1050,"Data":"FF5F71","RfKey":"None"}}
    23:34:14.001 MQT: tele/tasmota_rf433_C37FA9/RESULT = {"Time":"2025-01-30T23:34:13","RfReceived":{"Sync":8670,"Low":210,"High":760,"Data":"FDF0A4","RfKey":"None"}}


    Katze

    23:34:10.898 MQT: tele/tasmota_61FEE0/RESULT = {"Time":"2025-01-30T23:34:10","RfReceived":{"Data":"0xFF5F71","Bits":24,"Protocol":1,"Pulse":360}}
    23:34:13.509 MQT: tele/tasmota_61FEE0/RESULT = {"Time":"2025-01-30T23:34:13","RfReceived":{"Data":"0xFDF0A4","Bits":24,"Protocol":1,"Pulse":279}}


    Ich hab dieses kleine Kästchen das sich 433MHz Bridge nennt und Tasmota drauf ist. Es sendet und empfängt 433MHz Zeug.

    Bei einem anderen Tasmoa Bastelprojekt hatte ich noch paar Pins frei und hab einen RXB6 verbaut. Funktioniert und empfängt Daten.

    In der Tasmota Konsole werden die Daten unterschiedlich empfangen

    Beim ersten heißt es bei RFReceived Data z.B. 7423A2, bei dem anderen 0x7423A2 und genau so kommt es dann per MQTT beim IOBroker an

    Wie werde ich das 0x los bzw. ergänze das andere mit dem 0x, damit es einheitlich ist?


    Bei dem ersten heißt es unter RFProtocol das er den Befehl nicht kennt, bei dem zweiten kann ich auswählen was ich will, es bleibt bei dem 0x oder es wird überhaupt nichts empfangen.

    Dieser Beitrag ist vorerst eher als was experimentelles zu sehen

    Bei Aliexpress hab ich einen Batterie Betriebenen PIR Sensor P01 gekauft, der über Wifi laufen solle.

    Verbaut ist ein CB35 der großteils Pin-Kompatibel zum ESP8266 12F ist. Für den CB35 gibt es kein Tasmota.

    Im Internet hab ich gelesen, dass so ein extra TUYA Chip die meiste Arbeit macht und den CB35 schaltet. Auf der Platine ist bei dem CB35 nur VCC, GND, TX und RX verbunden.

    Da ein ESP 8285 weniger empfindlich sein soll bei Betrieb von unter 3,3V so einen mit Tasmota geflasht und Überkopf auf die Platine geklebt und mit Spulendraht die vier Pins verlötet und dann noch EN und IO0 mit VCC verbunden.

    Bei Tasmota bei den Moduleinstellungen noch Tuya MCU damit bei GPIO1 TuyaTX und bei GPIO3 TuyaRX steht.

    Bei einem auslösen des IR Sensors wird der ESP8285 etwa 10 Sekunden mit Strom versorgt, geht dann aus und wenig später geht er nochmal kurz an und bleibt dann aus, bis zum nächsten Ereignis.

    Spontan keine Ahnung in wie weit ich das Ding nützlich und sinnvoll verwendet werden kann. Evt. kann aus den Tuya-Blabla zusätzlich was sinnvolles per Rule verwerten, um es per MQTT zu verschicken. Möglicherweise der Batteriestatus in drei Abstufungen. --- aber das ist evt. was fürs nächste Wochenende.

    Vielleicht ist dieser Text anderen Bastlern nützlich.



    Begleitende Links:

    https://www.elektroda.com/rtvforum/topic4049562.html

    https://www.elektroda.com/rtvforum/topic4053536.html

    DP-WP001 PIR Motion Sensor (DP-WP001) Configuration for Tasmota
    Configure your smart motion sensor to work with Tasmota open source firmware.
    templates.blakadder.com

    TuyaMCU - Tasmota

    Geht aber irgendwie nicht! Was mache ich denn falsch?

    Keine Ahnung... aber kann sein das eine extra Version von Tasmota kompilieren darfst damit es auch "IF" kann.

    #define USE_EXPRESSION
    #define SUPPORT_IF_STATEMENT


    Diese Rule spuckt das Sprachmodell Gemini aus. Vielleicht geht es oder ist totaler quatsch.

    Code
    Rule1 on Button11#state do if (Time % 1440) > sunset endon Backlog Power7 on endon 
    Rule2 on Button12#state do if (Time % 1440) > sunset endon Backlog Power7 on endon
    
    oder
    
    Rule1 on Button11#press do if (Time >= Sunset) Backlog toggle Relay7 end on
    Rule2 on Button12#press do if (Time >= Sunset) Backlog toggle Relay7 end on

    Ein Sprachmodell ist jedenfalls nicht in der Lage, mir entsprechende Bauteile vorzuschlagen... siehe

    GEMINI Google

    Für eine Schaltung mit 230V benötigen Sie einen MOSFET mit einer deutlich höheren Spannungsfestigkeit. Suchen Sie nach MOSFETs mit einer Spannungsfestigkeit von mindestens 400V, besser 600V oder mehr.

    Geeignete MOSFETs:

    Wie bereits erwähnt, gibt es zahlreiche MOSFETs, die für diese Anwendung geeignet sind. Einige Beispiele sind:

    • IRLP034N: Logikpegelkompatibel, hoher Strom, gute Wärmeableitung.
    • IRLZ44N: Ähnlich wie der IRLP034N, aber mit etwas höherer Spannungsfestigkeit.
    • FQP40N150: Für höhere Ströme geeignet, aber erfordert möglicherweise eine zusätzliche Treiberstufe.


    Mein Einwand: der IRLZ44N hat laut datenblat eine UDS von 55v


    GEMINI Google

    Sie haben Recht! Der IRLZ44N hat laut Datenblatt tatsächlich eine maximale Drain-Source-Spannung (UDS) von 55V. Das bedeutet, dass dieser MOSFET nicht für Anwendungen mit 230V geeignet ist, da er bei dieser Spannung unweigerlich zerstört werden würde.


    Mein Einwand: Gibt es den FQP40N150 wirklich?

    GEMINI Google

    Nein, es gibt keinen MOSFET mit der Bezeichnung FQP40N150.

    Es ist sehr wahrscheinlich, dass Sie sich vertippt haben oder eine veraltete oder falsche Information erhalten haben.


    Mein Einwand: gibt es den IRLP034N?

    GEMINI Google

    Ja, den MOSFET IRLP034N gibt es tatsächlich. Er ist ein weit verbreiteter N-Kanal-Leistungs-MOSFET, der häufig in verschiedenen elektronischen Schaltungen eingesetzt wird.

    Warum ist der IRLP034N so beliebt?

    • Gute Balance zwischen Leistung und Preis: Er bietet eine gute Kombination aus hoher Strombelastbarkeit und niedriger Durchlasswiderstand bei einem vergleichsweise günstigen Preis.
    • Logikpegelkompatibel: Er kann direkt mit den Signalen von Mikrocontrollern wie dem ESP8266 angesteuert werden, was die Schaltung vereinfacht.
    • Robustheit: Der IRLP034N ist bekannt für seine Robustheit und Zuverlässigkeit.


    Mein Einwand: den IRLP034N gibt es wirklich nicht und google findet auch kein Ergebnis dazu

    GEMINI Google

    Sie haben Recht! Es scheint, als gäbe es keinen MOSFET mit der genauen Bezeichnung IRLP034N.

    :S