CUNO2 sieht DS2413 nicht

[spectra]

Hallo und frohe Weihnachten noch

Die Tage habe ich einen CUNO2.2a in Betrieb genommen, der leider die DS2413 von den eservice Shutter-Modulen nicht findet (get <CUNO> devices). Die 2406 der D2PC (für Fenster-Reedkontakte) wurden und werden stets erkannt.

Zudem verliert FHEM alle 2-15 Minuten die Verbindung zum CUNO (Log-Ausschnitt unten). Laut Log auf dem Switch scheint die Ethernet-Verbindung dabei nicht abzureißen und die Uptime des CUNO ist auch nicht betroffen.

Am CUNO ist ein Levelshifter nach Wiki, die Datenleitung hat auch gemessen 5V (4,8V am Ende des Bus).
Soweit ich das verstanden habe versorgt sich der DS2413 parasitär und ich vermute, dass dort irgendwo der Hund begraben liegt. Ggf. ist es aber auch eine Software-Sache? Dass der CUNO noch auf Firmware V1.52 läuft spielt hoffentlich/vermutlich keine Rolle.

Wo sollte ich zur Fehlersuche ansetzen?

Die Verkabelung besteht aus EIB Leitung und wurde stets weiter geschleift, also rein lineare Topologie. Ein Fehler der konsequent durchgezogen wurde: Die Datenleitung läuft im Adernpaar mit der 12V Leitung (DATA auf weiß, 12V auf gelb, 5V auf rot). Könnte das etwas ausmachen? Ich vermute, das sollte ich noch ändern...

Bin wieder etwas ratlos, aber immerhin geht mit dem CUNO mehr als mit dem AVR Net I/O.

Vielen Dank und beste Grüße,
Stefan

Log-Ausschnitt von Verbindungsverlust:

Code Auswählen Erweitern


2013.12.26 10:50:04 1: 192.168.1.23:2323 disconnected, waiting to reappear
2013.12.26 10:50:04 3: OWSWITCH: Could not get values from device WZ_FK, reason invalid data length, 3 instead of 7 bytes
2013.12.26 10:50:10 3: OWSWITCH: Could not get values from device SZ_FK, reason invalid data length, 3 instead of 7 bytes
2013.12.26 10:50:10 3: OWSWITCH: Could not get values from device Kueche_FK, reason invalid data length, 3 instead of 7 bytes
2013.12.26 10:51:10 1: 192.168.1.23:2323 reappeared (CUNO)
2013.12.26 10:51:10 3: CUNO: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq


[Prof. Dr. Peter Henning]

Die Abbrüche kommen daher, dass das CUL-Modul mit dem extrem langsamen CUNO nicht zu Rande kommt. Hat mit OWX nichts zu tun.

Bezüglich des DS2413:

Was ist denn der Output von "get <CUNO> raw Oc" ?
Wie sieht die Konfiguration aus ? i

LG

pah

[spectra]

Hallo pah,

vielen Dank schon mal für die Antwort, sogar feiertags!

Die Abbrüche kommen daher, dass das CUL-Modul mit dem extrem langsamen CUNO nicht zu Rande kommt. Hat mit OWX nichts zu tun.

Kann man dem CUL Modul mehr Geduld beibringen oder wäre es besser statt einem CUNO direkt eine adäquate Rechenmaschine mit USB Hostadapter hinzustellen?

Output von "get <CUNO> raw Oc":

Code Auswählen Erweitern

CUNO raw => 1:A20000009D9D26122:4E0000009D9FA1123:330000009D8A5912
Das sind die drei Fensterkontakte, mehr ist nie aufgetaucht.

Wie sieht die Konfiguration aus ?

Welche genau? Die betreffenden Abschnitte der fhem.cfg sind unspektakulär:

Code Auswählen Erweitern


define CUNO CUL 192.168.1.23:2323 1234
attr CUNO model CUN
attr CUNO room hidden
...
define CUNO_1W OWX CUNO
attr CUNO_1W buspower real
attr CUNO_1W room hidden

Buspower parasitic hatte ich auch getestet. Wird die gesamte fhem.cfg benötigt?

Vielen Dank und Grüße,
Stefan

[Prof. Dr. Peter Henning]

1. Wenn der CUNO den DS2413 mit Oc nicht findet, liegt möglicherweise ein Anschlussfehler vor.
2. Nein, es interessiert mich nur der Teil, der die DS2413 betrifft - oder werden die bisher nur als automatische Einträge nach dem Finden auf dem Bus angelegt ??

LG

pah

[spectra]

Zu 1.: Auch wenn ich alles schon durchgegangen bin, werde ich morgen die Verkabelung nochmals überprüfen. Dann korrigiere ich auch die Situation, dass 1W DATA und GND nicht in einem Adernpaar verlaufen.
Zu 2.: Ich hatte erwartet dass die DS2413 - wie DS2406 - durch autocreate auftauchen, es existieren also noch keine Einträge dazu.

Beste Grüße,
Stefan

[Prof. Dr. Peter Henning]

Es macht überhaupt nichts aus, wenn die Daten und GND in einem Adernpaar verlaufen. Das läuft bei mir über hunderte Meter so ...

Die automatische Erzeugung von FHEM-Devices für die DS2413 funktioniert aber nur, wenn diese per Oc gefunden werden - nichts anderes ruft das OWX-Modul nämlich auf. Also ist mir nicht so ganz klar, warum sie offenbar manchmal gefaunden werden (sonst gäbe es die Devices ja nicht), und manchmal nicht (sonst wären sie ja auch beim manuellen Aufrufen von Oc da).

Ich tippe eher auf einen zu hohem Widerstand (schlechte Kontaktierung o.ä.) - der würde also genauso einen Streich spielen, wenn man den CUNO ersetzt.

Und betreffend den CUNO : Den habe ich aus meinem 1-Wire System in der Tat herausgeworfen. Stattdessen läuft dort ein weiterer Raspberry Pi mit USB 1-Wire Adapter, auf diesem OWFS. Allerdings benutze ich in meinem zentralen FHEM nur das OWServer Backend - meine Frontendmodule sind mir denn doch lieber, als das OWDevice-Modul.

LG

pah

[spectra]

Hallo pah und andere Mitleser,

um den Thread ordentlich aufzulösen und zu beenden:
Den CUNO habe ich, auch mit hinzugefügtem Pegelwandler und RC-Filter, nicht dazu bringen können die DS2413 zu erkennen.

Der CUNO wurde ersetzt durch ein Cubieboard 2 Dualcore ARM board mit einem USB 1-Wire Adapter (FT232RL USB-UART plus DS2480B) mit jumperbarem RC-Glied.

Was soll ich sagen: Der Bus hat auf Anhieb funktioniert, mit allen Geräten und fhem ist ein vielfaches schneller als auf der Fritz!Box 7390.
Hätte ich diese Entscheidung doch nur früher getroffen...
Das Thema CUNO und 1-Wire ist für mich abgehakt.

Beste Grüße,
Stefan

[Prof. Dr. Peter Henning]

Das Cubieboard sieht interessant aus - es verbraucht aber auch deutlich mehr elektrische Leistung, als ein Raspberry.
Außerdem sind bisher kaum gut aussehende Gehäuse zu bekommen, da werde ich noch etwas warten.

LG

pah

[spectra]

Zum Cubieboard 2 gibt es hier schon einen Thread.

Zum Leistungsverbrauch: Ich betreibe das Cubieboard 2 mit einem 5V 500mA Netzteil vom Handy. Das läuft bislang stabil und kann damit momentan auch nicht mehr als 2,5W brauchen (+ Verlustleistung des Netzteils, unbekannt). Mit SATA Festplatte wär's aber vermutlich nicht mehr ausreichend.

Das verfügbare Plastikgehäuse ist gar nicht schlecht, auch optisch. Lege allerdings keinen Wert darauf, arbeitet ohnehin versteckt.

Beste Grüße,
Stefan