@ronny22 sagte in Jeelink und Technoline, keine Daten im Log: Operating System: Ubuntu 23.04 Abgekündigt, nimm da was lebendiges... *** Time and Time Zones *** Local time: Sun 2024-06-16 10:51:20 UTC Universal time: Sun 2024-06-16 10:51:20 UTC Setz da die richtige Zeitzone. Das Debug-Log schaust du dir am besten im vollen an. Per iob logs

@thomas-braun Danke. Den Rechner runterfahren und per schaltbare Steckdose vom Strom trennen hat zum Glück gereicht das Zigbee nun wieder voll funktioniert :blush: Vorherige Rebootvorgänge hatten es nicht gelöst.

ich bin schon auf das nächste Problem gestoßen. Das Wavesharemodul habe ich an einen ModbusUsb-Stick angeschlossen. Ich möchte gerne ein paar Daten von dem W-Modul zum M-Stick schicken um die Verbindung zu Testen. Ich habe im Modbusadapter vom W-Modul im Register 3, 3 Float Datenpunkte angelegt. Im Modbusadpater vom M-Stick habe ich ebenfalls die 3 Register angelegt. Leider werden die Daten nicht übertragen. Ich habe zuvor mit dieser Hardwarekonstellation Daten vom Modul zum Stick schicken können, die Verkabelung dürfte also passen. Hier ist die Konfig vom Modubus USB Stick [image: 1718471060544-statususbstick.png] [image: 1718471071603-konfigusbstick.png] [image: 1718471080053-konfigusbstick2.png] Hier ist die Konfig vom WaveshareModul [image: 1718471134800-konfigwmodul.png] [image: 1718471144179-konfigwmodul2.png]

@chaot Danke für den Tipp

@stefan7816 Genau so würde ich es machen, allerdings kannte ich die Shelly RGB Geschichte noch nicht, deshalb habe ich es diskret gemacht mit einem ESP, bzw. Wemos, der mir die drei, bzw. vier Farben gemacht hat und dann auf fertige N-MOS Treiber weitergeleitet. Bei einem Nachbarn hatte ich aber dann, nach der Shelly Entdeckung, RGB Gartenspots damit angesteuert. Auf den Shelly hatte ich WLED aufgeflasht um es über WLED zu steuern. Dort sind noch viele weitere LED Beleuchtungen wie auch Pool (über DMX) per WLED angeschlossen. Hier hat man den Vorteil alle auf einmal zu syncen.

@acidsubway Die Funktion/Fehlfunktion hängt mit der Auswahl und Konfiguration deines GPIOs zusammen. Ersteinmal zeigt Deine Zeichnung D6 und Du sprichst von D5. Welchen GPIO verwendest Du wirklich und ist es tatsächlich ein D1 Mini? In diesem Fall (D5/D6) zieht keiner dieser GPIOS beim Booten in eine Richtung (High/Low) insofern dbzgl. schon mal unkritisch. Dieser 1300mAh LiPolymer-Akku bzw das Sysmbol iritiert mich auch. Hat das einen tieferen Bezug zur Realität? Was die gewählte "Default" Konfiguration von D5/D6 ist kann ich dir aus der Hüfte nicht sagen. Das Auswahlmenü in ESPEasy lässt für einen Eingang/Input aber nur die Konfiguration als Pullup zu heißt der Eingang ist im Standard auf Spannung (3,3V) hochgezogen. Schaltet Dein Alarm jetzt darauf (~2,5V) wird das nicht detektiert. [image: 1717843712365-181f086d-35be-4017-a78e-5c45cf192147-grafik.png] Für einen Eingang zB Push-Buttons ziehe ich üblicherweise auch mit dem Button gegen GND und der logische 0 Zustand des Eingang ist High/3,3V. Mag sicher auch anders gehen aber mit einem PC817 Modulboard für 1€ ist der Drops erledigt und hat noch eine gescheite galvanische Trennung zwischen dem Pumpfix und dem ESP-Kreis. [image: 1717911441302-screenshot_20240609-073627.png]

Guten Morgen zusammen, Ich wollte keinen separaten Thread aufmachen, deswegen frage einfach hier. Bei mir zu Hause sind 7 Fenster mit dem 2Ch Sonoff Schalter installiert und mit Tasmota gefälscht. Bei zwei letzten Fenster habe ich bei der Installation etwas schief gemacht, kriege es nicht mehr logisch kalibriert. Programmiert sind sie so, dass sie morgens auf 100% Open fahren und abends auf 30% abdunkeln. Ich schildere kurz das Problem. Wenn ich das Fenster ganz aufmache (power1), ist die Rolllade ganz oben und das Fenster ist somit offen, steht auf 100% Open bei den Datenpunkten in ioBroker. Nach ein paar Tagen merke ich, dass die Rollladen bei 100% immer mehr durchhängen, bis sie irgendwann nach einer Woche mit halb verdunkelten Fenster stehen, obwohl im Datenpunkt 100% Open steht. Ich weiß, dass ich sie falsch kalibriert habe, stehe aber auf dem Schlauch und bekomme es nicht mehr hin. Abhilfe schafft es, wenn ich die Rolladen mit power2 ganz zu mache, dann mit power1 ganz auf, so steht Macher das Fenster offen. Das nervt aber natürlich, jede Woche das durchzuführen. Vielleicht findet jemand Zeit und Lust mir den Fehler zu erklären. Danke im Voraus

@andre1000 Gibt es hier was neues? Stehe auch gerade vor einem solchen Projekt. Funktioniert der im ersten Post genannte Controller in Verbindung mit allen Wiegand Fingerprintsensoren und kann er mit dem Adapter in iob eingebunden werden? Danke!

@xadox Für den ioBroker hab ich ja einen Adapter erstellt ( https://github.com/ltspicer/ioBroker.heizoel24-mex ) ;) Und hier ist die aktuelle Version vom Script: https://github.com/ltspicer/heizoel24.mex

kannst du es mit npm start laufen lassen ?? oder ist es nur als service, der nicht startet ?? wo läuft z2m ?? auf nem pi ?? lxc ?? vm ?? docker ?? @mickym sagte in Nativ zigbee2mqtt Error Code 1 in Config Datei: @jan-lange Welchen Chipsatz hast Du denn? was hat der chipsatz damit zu tun ??

@mcu ich vermute mal die Einspeisung der Versorgungsspannung am Ausgangsanschluss.

@arteck Danke für den Rat. Ich habe gestern nvbackup.json gelöscht. Und dann das Zigbee Netz neu aufgebaut. Eine Heidenarbeit. Danke BiBo

@thomas-braun Top :+1: Besten Dank dafür. Dann schau ich nachher mal, was der alles anbietet an Daten.

Habs jetzt noch mal versucht und wenn ich den Typ ebenfalls auf den init Wert stehen lass, dann bekommt er die Verbindung aufgebaut. Aber auch wirklich nur dann und wie in dem anderen Post nur mit dem Standard Werten. [image: 1717410341638-deeeec45-353a-40e2-955b-34158770c162-image.png] Habe inzwischen auch mal ein Conbee testen können. Da klappt alles problemlos.

@all hab da was gefunden auf S.28/29. Ob das allerdings für die WP von @Scho gilt!? Bedienung & Installation und es gibt die Modbusplatine offenbar als Zubehör Modbus Ochsner

Ich habe einen neuen shelly plus i4 installiert, und dieser verhält sich genauso wie der 1PM und der 2PM. Ich bekomme auch ihn nicht in den iobroker. Aber ich kann die die debug logs miteinander vergleichen und habe signifikante Unterschiede festgestellt. Bei den nicht funktionierenden Geräten sehen die einzelnen Blöcke etwa so aus : "ts": 1717339374.151, "level": 2, "data": "shos_mqtt_conn.c:601 MQTT0: Connecting to 192.168.1.125:8082 (192.168.1.125:8082)" "ts": 1717339374.168, "level": 0, "data": "shos_mqtt_conn.c:489 MQTT0: Connect status 256" "ts": 1717339374.174, "level": 2, "data": "shos_mqtt_conn.c:844 MQTT0: Connecting after 6976 ms" Die Geräte, die vom iobroker erkannt werden machen das so : "ts": 1717339522.581, "level": 2, "data": "shos_rpc_inst.c:230 Input.GetConfig via HTTP_in GET 192.168.1.125:51114", "fd": 1 "ts": 1717339522.661, "level": 2, "data": "shos_rpc_inst.c:230 Shelly.GetStatus via HTTP_in GET 192.168.1.125:51116", "fd": 1 "ts": 1717339522.693, "level": 2, "data": "shos_rpc_inst.c:230 Shelly.GetDeviceInfo via HTTP_in GET 192.168.1.125:51124", "fd": 1 Die shellys , die mit dem iobroker kommuniezieren, machen das mit diesen GET Anfragen über HTTP, das fehlt bei den neuen Geräten. Leider weis ich nicht wo das herkommt . Die Firmware ist bei den Geräten gleich. Habe ich irgendwo was falsch eingestellt. Ich bin Ratlos.

@asgothian Ich habe die seit zwei Jahre. Verbindung stabil. Abstand zum Koordinator ca. 8m