[gelöst] CUNX - Bedeutung der LEDs

Begonnen von Jorge_W, 25 Januar 2018, 11:59:22

Vorheriges Thema - Nächstes Thema

Jorge_W

Hallo zusammen,

ich bin gerade dabei mich in das Thema Hausautomatisierung einzuarbeiten.
Zu diesem Zweck habe ich erfolgreich einen Raspi mit Fhem versehen und als ersten Test ebenso erfolgreich meinen Fernseher eingebunden.
Der nächste Schritt wäre die Integration meiner bestehenden FS20 Struktur (in der Hauptsache Beleuchtung) über einen CUNX.

Mein Problem:
Den CUNX habe ich IMHO erfolgreich über den Raspi geflasht.
Zumindest gab es keien Fehlermeldung und der Verifyzähler lief durch.
Nach ...START und nach Wiederkehr der Versorgungsspannung  blinkt die LED aber munter orange-rot und der CUNX meldet sich NICHT beim Router an.

Meine Frage:
Kennt jemand die Bedeutung der LEDs am CUNX?
- kleine grüne beim Mini-USB scheint klar: Power On
- LEDs am Netzwerkanschluss sollten auch klar sein.
- Die LED beim Minischalter: Wann leuchtet die wie? Farbe? Blinkmuster?

Beim Hersteller und im WWW habe ioch dazu nix gefunden...

Danke für jeden Hinweis!

Grüsse, J.

KernSani

Hmmm... nachdem hier niemand reagiert, vielleicht im SlowRF Unterforum versuchen? (Verschieben Button findest du ganz unten links)
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Jorge_W

#2
(Erfolgreich verschoben)

Vielleicht trägt diese Information zur Lösungsfindung bei.
Anfangs dachte ich, die Meldungen nach ...flash waren OK.
Validierung ohne Fehler und eine Meldung, dass ewtas verbraucht wurde.
Beim 2ten Mal hinsehen habe ich nun einen Verdacht. Aber der Reihe nach:

1. Zunächst Speicher löschen. Auf das Kommando

$ sudo dfu-programmer atx128a4u erase

gibt es gar keine Meldung. Die LED am CUNX bleibt dunkel. Das Raspbian Prompt erscheint nach einer Sekunde wieder.

2. Dann Flashen

$ sudo dfu-programmer atx128a4u flash CUNX.hex

ergibt diese Reaktion:

Valdating...
50370 bytes used (40.99%)

LED bleibt dunkel, Prompt erscheint wieder.

Nach Power On oder nach "...dfu-Programmer ... start" fängt die LED des CUNX munter an zu blinken. So etwas wie Rot. Das Gerät scheint aber nicht zu starten, der Router sieht auch keinen neuen Netzteilnehmer.

Jetzt mein Verdacht:
Das file CUNX.hex hat 139kB (141690B), übertragen wurden aber nur rund 50kB.
Also ist irgendwie das Flashen unterbrochen worden. Da das aber immer an derselben Stelle geschieht, muss ich doch davon ausgehen, das der Speicher des CUNX defekt ist?

Kann mir jemand diesen Verdacht bestätigen oder auch widerlegen.
Vielleicht übersehe ich schon seit Tagen irgend etwas immens wichtiges...

Danke nochmal.
Grüße, J.

noansi

Hallo Jorge,

ZitatDas file CUNX.hex hat 139kB (141690B), übertragen wurden aber nur rund 50kB.
Das hex file ist naturgemäß größer als die Anzahl der Binärbytes die darin kodiert sind, Deine Interpretation ist also falsch.

Die orange LED neben der grünen blinkt üblicherweise langsam im 2s Takt, sofern nichts anderes eingestellt wurde.

Geht denn was am USB Port? Antwortet er da auf ein 'V' gefolgt von LF mit "V 2.67 CUL868"

Eventuell musst Du den CUNX via USB mit 'e' mal auf "Werkseinstellungen" zurück setzen.
Und eventuell DHCP für den Netzwerkanschluss aktivieren und/oder die Netzwerkeinstellungen setzen.
Siehe auch https://github.com/tostmann/culfw/tree/culfw-v2.x/Devices/CUNX.

Gruß, Ansgar.

Jorge_W

#4
Hallo noansi. Vielen Dank für die Tipps! Werde mich heute abend gleich dransetzen und berichten.
Das das Blinken normal ist - tss, wer macht denn sowas...

Noch eine Bitte kann mir Jemand eine komplette Beispielzeile notieren, mit der man den cunx dhcp aktiviert?
Bin halt noch eine Linux-nulpe...


Grüsse, Jörg.


Gesendet von iPhone mit Tapatalk

noansi

Hallo George,

in der fhem.cfg mit
################
# CUNX Test USB
################
define CUNX_WS868 CUL /dev/ttyACM0@38400 0000
attr CUNX_WS868 rfmode SlowRF
attr CUNX_WS868 room CUL
attr CUNX_WS868 verbose 1

einbinden und FHEM neu starten, falls er nicht per autodetect ohnehin automatisch erkannt wird.
Und dann kannst Du mit set (Button) raw (aus Liste daneben) die Befehle in FHEM an den CUNX senden, sofern er auf der Schnittstelle kommuniziert. Wenn nicht wird er in FHEM auf disconnected stehen.

Also erst mal set raw e gefolgt von Enter, zum Rücksetzen des EEPROM Inhalts inklusive Neustart des CUNX.
Dann set raw Wid01 gefolgt von Enter laut der readme.md.
Mit get raw En gefolgt von Enter sollte er die aktuelle Einstellung ausspucken laut der readme.md.

/dev/ttyACM0 gilt nur, wenn CUNX auch auf diese Schnittstelle gemappt wird.
Das Kommando dmesg in einem Terminalfenster eingegeben gibt Dir darüber Auskunft.

Wenn Du damit dann die Netzwerkeinstellungen angepasst hast, dann kannst Du die Definition auf die IP Adresse ändern, wenn Du dann immer noch die Netzwerkanbindung weiter treiben möchtest.
define CUNX_WS868 CUL <zutreffende IP Adresse eintragen>:2323 0000

Ansonsten wiki
https://wiki.fhem.de/wiki/CUL
https://wiki.fhem.de/wiki/FS20_Allgemein
https://wiki.fhem.de/wiki/Was_ist_der_Hauscode%3F
...

und Suche verwenden.

Gruß, Ansgar.

Jorge_W

Also:
Cunx lebt.
Wie beschrieben in Fhem angelegt: Status: initialised.

Reagiert auf ,,e" (gschwind disconnected, dann wieder initialised)

Mi ,,V" gibts auch die richtige Version zurück.

Nur DHCP geht immer noch nichts. Laut docs blinkt die led nur dann , wenn cunx nach keine adresse erhalten hat.
Nach ,,e" müsste DHCP defaultmässig aktiv sein.
Auf ,,Wid01" reagiert das Ding überhaupt nicht. Auch nicht auf ,,Wid00".
Mit ,,Rid" gecheckt, antwortet der Cunx immer mit ,,R0000 02/2".

Any ideas?

Danke soweit.
J.


Gesendet von iPhone mit Tapatalk

noansi

#7
Hallo George,

ZitatLaut docs blinkt die led nur dann , wenn cunx nach keine adresse erhalten hat.
Mag sein, aber nicht im realen Leben.  ;)
Damit ist die LED am Ethernet Port gemeint.

ZitatMit ,,Rid" gecheckt, antwortet der Cunx immer mit ,,R0000 02/2".
Bug in der Firmware, dass die Ri Kommandos nicht funktionieren, ebenso, wie das En nicht funktioniert. Kann ich bei meinem CUNX (V 2.67 CUL868) bestätigen (hatte Netzwerk auch noch nie probiert).

ZitatAuf ,,Wid01" reagiert das Ding überhaupt nicht. Auch nicht auf ,,Wid00".
Mag sein, aber es würde reichen, wenn es auf Wid01 einfach DHCP einschalten würde.  ;)
Wid01, dann Netzwerkkabel raus und wieder rein (ggf. PowerCycle). -> Bei mir geht es mit DHCP. Und die orange LED blinkt weiter (und dann natürlich auch die orange LED am Ethernet Port, und dort grün auf dauer an)

Probier doch ggf. mal manuell eine Adresse in Deinem Subnetz einzustellen. Die Wi Kommandos sollten zumindest was tun, auch wenn das Feedback = 0 ist.

Gruß, Ansgar.

Jorge_W

Morgen dann.
Danke für die Geduld.
Gute Nacht.
J.


Gesendet von iPhone mit Tapatalk

Jorge_W

Leider keinerlei Veränderung. An USB scheint alles zu funktionieren, am Netz geht gar nichts. Teurer Schrott.

Muss mich jetzt nach einer Alternative für Fhem mit FS20 umschauen.

Nochmal vielen Dank für die Mühe.

J.


Gesendet von iPhone mit Tapatalk

noansi

Hallo George,

ich habe es jetzt auch mal mit dem Netzwerkbetrieb des CUNX versucht.

Wid01 schaltet DHCP ein, denn meine FritzBox vergibt ihm dann eine IP Adresse. Nur leider klappt das dann wohl nicht mit der Übernahme ins reale Leben, sprich, es geht dann trotzdem nix. Auch keine Ping Antwort.

Aber wenn ich erst mal mit

Wid00 DHCP abschalte.

Und dann mit
Win255.255.255.0 die Netzmaske setze
Wigxxx.xxx.xxx.xxx das Gateway einstelle
Wiayyy.yyy.yyy.yyy eine freie IP Adresse in meinem Netzwerk einstelle

dann antwortet der CUNX auf ping yyy.yyy.yyy.yyy
und ich kann über den Port 2323 den CUNX und über Port 2324 das Pigatormodul ansprechen. Es geht also mit fester IP und nicht mit DHCP.

tostmann muss wohl mal die Firmware bezüglich Netzwerk überarbeiten.

Gruß, Ansgar.

Jorge_W

Was soll ich sagen?
Ins Blaue hinein mal die manuelle Vergabe probiert und hoppla: der Cunx meldet sich auf ein freundliches Ping!
Wer hätte das gedacht!
Einbindung in Fhem scheint gelungen. Wenn ich die ersten FS20 erfolgreich definiert und ansprechen konnte geht der Fred auf gelöst.
Nichtsdestotrotz: auch wenn die komplette Thematik für Bastler und Insider gedacht ist - ich bin von Art und Umfang der Dokumentation enttäuscht und der Zustand der Hardware entspricht nicht dem dafür aufgerufenen Preis. Seisdrum, so bleibt es halt eine Geheimwissenschaft.

Und deswegen nochmal ein ganz dickes Dankeschön an Ansgar!

Grüsse, J.


Gesendet von iPhone mit Tapatalk

Jorge_W

FS20 Komponenten lassen sich definieren bzw. auch autocreaten.
CUNX schaltet die richtigen Aktoren.
Für heute alles schön!

Wir merken uns: CUNX im aktuellen Ausgabestand ( V 2.67 CUL868 ) kann kein DHCP. Wer das Ding am Netz betreiben will, muss manuell Adressen vergeben (Gateway, Subnet nicht vergessen). Und die blinkende LED hat reinen Unterhaltungswert.

Fred kann zu.

Grüße, J.

saddelfest

#13
Hallo, nachdem es mir unter tatkräftigem Support von Klaus Moser gelungen ist meinen CUNX zu flashen, scheinen die Probleme nicht aufhören zu wollen. Ich mache gerade dei gleichen Erfahrungn wie die Beiträge hier beschreiben: Ihc bekomme den CUNX nicht an meinem Netzwerk (Fritzbox) angemeldet. Nach dem Flashen blinkt die helle mittlere LRD munter im 2 sec takt (rot-orange. Das scheint normal zu sein. De Power LED leuchtet dauerhaft grün ebenso wie die rechte LAN LED.
Die linke kleinen orange LAN LED blinkzt und das scheint ein zeichen dafür zu sein, dass keinen DHCP Adresse zugewiesen wurde. In meienr Fitzbox wird der CUNX auchnicht unter den netzwerkgeräten gelistet.
Wenn ich ihn über  USB mit dem Raspberry verbinde, scheint alles zu funktionieren (FS20 Geräte werden erkannt und könnnen geschaltet werden.  Aber unter LAN tut sich nichts. Im Endeffekt kann der CUNX derzeit in etwas das gleiche wie auch meine vorhandenen CUL Sticks. Dafür habe ich ihn mir eigentlich nicht gekauft.... Eigentllichwollte ich das PIGATOR Modul des CUNX nutzen aber davon bin ich derzeit gefühlt noch meilenweit entfernt.

Eine statische IP konnte ich bisher noch nicht zuweisen. Irgendwie  reagiert der CUNX nicht auf meine set CUNX_WS868 raw xx Befehle aus der FHEM Kommandozeile.

xx = e führt zu einem kurzen "disconnected" gefolgt von einem "initialized"
xx= Wid01 oder Wid00 haben keinen sichtbaren Effekt.

xx= V gibt die version V 2.67 zurück.
Bin im Moment relativ ratlos und auf der Suche nach Hilfe. Klaus hat mir noch ein paar Tipps gegeben, die ich ausprobieren werde, weil aufgeben und das Teil in die Ecke werfen will ich noch nicht.
Immerhin ist es gut hier Leidensgenossen zu finden, die vor ähnlichen Problemen standen. und letztlich das Teil doch noch zum laufe bekommen haben. Vor BUSWARE habe ich im Moment noch nicht viel Hilfe bekommen, außer den Hinweis, dass das wohl meine Fähigkeiten übersteigen würde. Als ich das teil gekauft habe, kam dieser Warnhinweis nicht.


Grüße,
Manfred




fiedel

Zitat von: saddelfest am 24 April 2018, 13:17:59
xx= V gibt die version V 2.67 zurück.
Bin im Moment relativ ratlos und auf der Suche nach Hilfe. Vor BUSWARE habe ich im Moment noch nicht viel Hilfe bekommen, außer den Hinweis, dass das wohl meine Fähigkeiten übersteigen würde.

Dann ist doch alles gut - dein CUNX funktioniert schon mal. Du musst nun nur noch diese Tipps befiolgen und du solltest Netzanbindung haben.
Der Tosti hat mir das damals auch gesagt und er hat auch meist Recht damit: Er verkauft ein Stück Hardware für Entwickler, die sich dafür eine eigene Firmware schreiben. Das können wir beide nicht. Er ist kein Laden für gebrauchsfertiges FHEM- Zubehör.  ;)
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423