nanoCUL mit a-culfw disconnected

[moerte]

Hallo ..
Ich habe enorme Verbindungsprobleme mit einem CUL welcher auf einen Raspberry mit ser2net läuft.

Mit der aktuellen normalen culfw läuft er permanent ohne Probleme.
Mach ich die a-culfw drauf, bricht die Verbindung ab und er geht auf disconected.

Er geht immer wieder auf disconnected.
In den Internals des CULs steht dann: RAWMSG: Port already in use

Wenn er disconected hab ich im logfile folgendes stehen:

Code Auswählen Erweitern


CUL_Parse: CUL_1 Port already in use
CUL_1: Unknown code Port already in use, help me!
192.168.2.186:2000 disconnected, waiting to reappear (CUL_1)



Hat jemand einen Tipp woran das liegen könnte?
Ich brauch da aber auch die a-culfw um meine Brandmeldeanlage zu steuern. Das kann die normale culfw leider nicht.

[moerte]

Muss das Thema nochmal hoch pushen, da ich bisher leider noch keine Lösung für das Problem gefunden haben

Nur eins und das habe ich oben angepasst. Mit der normalen culfw läuft es ganz normal

[Beta-User]

Du lieferst sehr wenig Infos:
- Original-Cul, oder?
- Den Remote-Rechner (mit ser2net) hast du mal neu gestartet?

Folgendes: Kann sein, dass sich bei einem ATMega32Ux die serielle Kennung ändert. Wenn du "by-id" auf dem ser2net-Rechner angebunden hast, kommt dann dort keine Verbindung mehr zustande.
Änlich ist es, wenn du ab- und wieder anstöpselst, aber nicht "by-id" verwendest: da wird die Schnittstelle hochgezählt (z.B. ttyUSB1 statt ttyUSB0).

Für FHEM dürfte sich keine Änderung ergeben, da wird der ser2net-CUL immer nur über IP+Port adressiert. Nur ist eben an der Stelle nichts zu finden, da nicht (richtig) eingebunden.

[moerte]

VielenDank für deine Antwort.
Es ist ein selbstbau nanoCUL den ich mal aus ebay gekauft hatte -
Wenn ich den Raspberry neustarte oder auch ein ser2net restart mache ist er wieder kurzzeitig Initialized - jedoch hält dieser Zustand nur kurz. Bin noch nicht dahinter gestiegen was es auslöst, dass er disconnected. Ich kann Schaltvorgänge machen und dann miteinmal ist er weg.

in ser2net habe ich Ihn wiefolgt eingebunden:L

Code Auswählen Erweitern


2000:raw:0:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0:38400


die a-culfw ist von heliflieger aus github:

https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=2ahUKEwiV4b3yxqbfAhXGalAKHZyHBSoQFjAAegQIBBAC&url=https%3A%2F%2Fgithub.com%2Fheliflieger%2Fa-culfw&usg=AOvVaw3RdJywLDgye2H4i3uhzGDd

[Beta-User]

Ah, ok.

Bei einem FTDI-Nano sollte das eigentlich nicht das Problem sein. Könnte ein Power-Problem sein iVm. dem hier: https://wiki.fhem.de/wiki/Arduino#FTDI-Resets

Außerdem weiß ich nicht, welche Baudrate die aculfw typischerweise nutzt. Aber wenn er an sich wenigstens ein paar Schaltvorgänge macht, kann das eigentlich auch nicht das Problem sein.

Bitte zukünftig die angepinnten Hinweise beachten, dann hätte sich die Rückfrage erübrigt. Hier wäre ein list vom CUL und die ser2net-Info sinnvoll gewesen .

[moerte]

will es jetzt nicht ausschließen das es ein Power Problem ist - aber mit der normalen culfw läuft er ja Prima ohne ausfälle??

Ja er macht Schaltvorgänge wenn ich ser2net restarte oder manchmal hilft auch ein reopen über Fhem.
aber dann schalte ich paar mal und er ist wieder nicht verbunden.

Ja sry - hätte ich gleich mit angeben sollen:/
aber hier noch ein list vom CUL (aktuell wieder disconnected) 

Code Auswählen Erweitern


Internals:
   CMDS       ABCeFfGiKLlMNRTtUVWXx
   CUL_1_MSGCNT 190
   CUL_1_TIME 2018-12-17 14:54:16
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        192.168.2.186:2000 0000
   DeviceName 192.168.2.186:2000
   FHTID      0000
   NAME       CUL_1
   NEXT_OPEN  1545054916
   NR         176
   PARTIAL   
   RAWMSG     Port already in use
   RSSI       -62.5
   STATE      disconnected
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-12-17 13:12:14   cmds             A B C e F f G i K L l M N R T t U V W X x
     2018-12-17 13:59:07   raw             No answer
     2018-12-17 14:54:16   state           disconnected
     2018-12-17 10:41:38   version         No answer
Attributes:
   rfmode     SlowRF
   room       System


[Beta-User]

Hmmm, wenn er wiederkommt (ggf. nach einiger Zeit, aber ohne Trennen von Power), ist es nicht der Testpin.

Das kann schon ein Power-Problem sein, wäre nicht das erste Mal, dass eine andere Firmware den Stromverbrauch eines Microcontroller-Geräts nach oben treibt; k.A. z.B., ob der CC1101 von der Leistung her anders konfiguriert wird...
Betreibe das Teil testweise mal an einem aktiven Hub. (Ggf. hilft auch ein besseres Netzteil vom Pi).

[moerte]

ja er kommt nach einer gewissen Zeit wieder - aber meist dauert das ewig.
nach einen ser2net restart eben:

Code Auswählen Erweitern


Internals:
   CMDS       ABCeFfGiKLlMNRTtUVWXx
   CUL_1_MSGCNT 200
   CUL_1_TIME 2018-12-17 15:02:56
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        192.168.2.186:2000 0000
   DeviceName 192.168.2.186:2000
   FD         52
   FHTID      0000
   NAME       CUL_1
   NR         176
   PARTIAL   
   RAWMSG     i11115416
   RSSI       -63
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-12-17 15:02:24   cmds             A B C e F f G i K L l M N R T t U V W X x
     2018-12-17 15:02:59   raw             isFF0F0F0FFFF0
     2018-12-17 15:02:56   state           Initialized
     2018-12-17 10:41:38   version         No answer
Attributes:
   rfmode     SlowRF
   room       System


Hatte schon ein 2.5 A Netzteil - ich such mal nach was größeren, hab noch paar daliegen.
wie kann ich denn testen ob der PIN26 auf Ground liegt? Lötkenntnisse hab ich auch keine

[Beta-User]

Wenn es das Tesp-PIN-Problem wäre, würde er NIE wiederkommen, es sei denn, der FTDI wäre zwischendurch stromlos gewesen. Wollte daher schon behaupten, dass es nicht Testpin sein kann, wenn er überhaupt wiederkommt, ABER:

initialized sagt eventuell nichts aus, außer, dass der _FTDI_ erreichbar ist (was nur bedingt Rückschlüsse darauf zuläßt, dass auch der dahinter liegende ATMega ansprechbar ist). Klappt "get CUL_1 ccconf"? Oder kannst du effektiv darüber was schalten?

[moerte]

ja wenn er initialized ist kann ich auch effektiv schalten und die ccconf gibt er mir auch aus:

Code Auswählen Erweitern


CUL_1 ccconf => freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB


jetzt läuft er z.B. seit dem letzten ser2net restart bis jetzt ohne Verbindungsverlust - warte schon jede Sekunde drauf das er wieder weg ist

[Beta-User]

Dann bin ich wirklich bis auf die Sache mit dem aktiven Hub ratlos...

[moerte]

Dann bin ich wirklich bis auf die Sache mit dem aktiven Hub ratlos...

Danke - ich bin eben auch Ratlos
Bin eben noch auf der Suche nach einen anderen Netzteil. Ein aktiven Hub hab ich nicht da (nur einen ohne Netzteil).
Werde dies mal noch testen. Weiß nur nicht ob z.b. ein neuer CUL (original) das Problem gleich lösen würde. Sonst würde ich das definitiv investieren.

[moerte]

gerade Beim Schalten der Weihnachtsbaumbeleuchtung gesehen dass er sich wieder verabschiedet hat .. aber hat sich nach 1min wieder selber verbunden - ohne das ich was gemacht habe.
Ein stärkeres Netzteil wie 2,5 A hab ich noch nicht gefunden - muss da nochmal die elektokisten durchstöbern.

hier der log: (Baum_1 wird über einen anderen CUL geschaltet, Baum_2 über den CUL_1 mit a-culfw)

Code Auswählen Erweitern


2018.12.17 16:29:57 3: CUL_1 IT_set: Baum2 on
2018.12.17 16:30:00 1: 192.168.2.186:2000 disconnected, waiting to reappear (CUL_1)
2018.12.17 16:30:00 2: IT IODev device didn't answer is command correctly:   raw => No answer
2018.12.17 16:30:03 3: CUL433 IT_set: Baum1 on
2018.12.17 16:30:10 3: CUL433 IT_set: Baum1 off
2018.12.17 16:30:11 3: CUL_1 IT_set: Baum2 off
2018.12.17 16:30:11 2: IT IODev device didn't answer is command correctly:   raw => No answer
2018.12.17 16:31:08 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.12.17 16:31:09 3: CUL_1: Possible commands: ABCeFfGiKLlMNRTtUVWXx
2018.12.17 16:31:09 1: 192.168.2.186:2000 reappeared (CUL_1)



[Beta-User]

Versuche doch ggf. erst mal, die Sendeleistung runter zu nehmen...

[moerte]

Versuche doch ggf. erst mal, die Sendeleistung runter zu nehmen...

Ok .. Versuche es mal mit x07 .. erstmal noch Netzteil finden