[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

saddelfest

#15
Naja, so ganz scheint das Problem noch nicht gelöst. Der Stand ist der Folgende:
Wenn ich den CUNX mit dem USB Port des Raspberys verbinde (wie von Noansi beschrieben, reagiert er wie ein normaler CUL USB Stick. Wenn ich ihn  in "SlowRF" mode setze, merkt er, wenn ich meine  FS20 Aktoren bediene und legt diese auch in FHEM an und alles lässt sich, wie  (von meinem CUSL-Stick) gewohnt, schalten.
Wenn ich den CUNX über LAN anspreche

define CUNX_WS868 CUL <zutreffende IP Adresse eintragen>:2323 0000, dann geht er auf "initialized" aber wenn ich jetzt FX20 Aktoren bediene, werden diese nicht automatisch erkannt AUTOCREATE ist wie vorher aktiv.
Der CUNX ist also doch kein "CUL über LAN". Ich hatte mir den CUNX eigentlich gekauft ,weil ich auch in meinem Heizraum, der außerhalb der Reichweite meiner CUL Sticks liegt FS20 Aktoren betreiben wollte. Ich wollte dazu den CUNX über LAN im Heizraum aufstellen. Das scheint aber nicht so einfach zu gehen. Oder mache ich etwas falsch? Wollte es vermeiden, ein 10 m  langes USB Kabel in den Heizraum zu legen. Außerdem wollte ich dann in einem zweiten Schrittim Heizraum über das PIGATOR Modul OW-Sensoren zur Temperaturüberwachung anschließen und mit FHEM auslesen. Davon bin ich noch Meilenweit entfernt. Darüber habe ich bisher noch kaum Infos gefunden. Das Pigator Modul kann ich über den Port 2324 ansprechen (jedenfalls kommt die Meldung "started"). Wie ich aber Devices auslesen kann,  ist mir noch nicht klar. Muss ja wohl zunächst ein OW Server definieren und dem irgendwie dem PIGATOR Modul zuweisen...   

fiedel

#16
Bist du weiter gekommen? Eigentlich sollte das Gerät über LAN genau so arbeiten wie an USB. Ich hab noch den CUNO und da ist das auch so. Er muss im Netzwerk natürlich auch von FHEM uneingeschränkt erreicht werden können.

Wenn du noch erweitern willst, weiß ich nicht ob Pigator wirklich so eine gute Idee ist. Für das Busware- Zeug braucht man gute Anleitungen und/oder viel Wissen. Wenn dort sowieso schon Netzwerk ist, könntest du einen abgesetzten Raspi Zero dort einsetzen und mit USB- CUL und USB- 1- Wire- Adapter ausstatten. Auf den Zero kommt dann entweder auch FHEM (Verbindung beider FHEM per FHEM2FHEM) oder nur Ser2Net um die Schnittstellen an den Hauptrechner durchzureichen. Dafür gibt es auch mehr Lesestoff in Forum und Netz. 

Da du das Zeug nun schon mal hast, ist es aber auch eine schöne Herausforderung das doch zum Laufen zu bekommen. Ich lasse sowas dann meist erst mal liegen und lese mich nach und nach tiefer in die Materie ein. Irgendwann reichen die Infos dann aus und plötzlich ist alles ganz einfach...  ;)
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