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:
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.
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
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.
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
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
(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)
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 ;) .
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) :-(
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
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).
ja er kommt nach einer gewissen Zeit wieder - aber meist dauert das ewig.
nach einen ser2net restart eben:
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 :-(
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?
ja wenn er initialized ist kann ich auch effektiv schalten und die ccconf gibt er mir auch aus:
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
Dann bin ich wirklich bis auf die Sache mit dem aktiven Hub ratlos...
Zitat von: Beta-User am 17 Dezember 2018, 15:33:42
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.
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)
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)
Versuche doch ggf. erst mal, die Sendeleistung runter zu nehmen...
Zitat von: Beta-User am 17 Dezember 2018, 17:04:55
Versuche doch ggf. erst mal, die Sendeleistung runter zu nehmen...
Ok .. Versuche es mal mit x07 .. erstmal noch Netzteil finden :D
So kleine Rückmeldung..
Hab ein USB hub Netzteil mit 4,5A angeschlossen, leider besteht das Problem weiterhin.
Auch ein herabsetzen der Sendeleistung bringt leider nichts.
Was mir noch auffällt, dass mein anderer CUL vom Hauptraspberry (CUL433) auch immer mitsendet. Obwohl ich das Attribut IOdev dem CUL_1 zugewiesen habe. Vlt stören die beiden sich und dann bricht die Verbindung vom CUL_1 ab?
Kleiner Auszug nochmal aus dem Log:
2018.12.18 08:35:27 3: CUL433 IT_set: Bogen_Bad off
2018.12.18 08:35:28 3: CUL_1 IT: Bogen_Bad off->off
2018.12.18 08:35:30 3: CUL_1 IT_set: Bogen_Lucy_links off
2018.12.18 08:35:30 3: CUL433 IT: Bogen_Lucy_links off->off
Hmm, also der Aufbau war (anderes Netzteil)-Pi-aktiver Hub-CUL?
Dann dürfte es nicht an der Stromversorgung liegen.
Und die beiden CUL kommen sich m.E. nur insoweit "in die Quere", dass der eine das empfängt, was der andere sendet. Das ist ganz normal.
Dann ist es entweder die Hardware, oder die Störung kommt aus dem Netzwerk (typischerweise: PowerLAN, gelegentlich auch WLAN - v.a. Pi-WLAN+Fritzbox ist "berüchtigt").
Mhhh- ja die Stromversorgung kann ich denk jetzt ausschließen.
Ich mach jetzt mal noch eins .. da auf dem raspberry ja wirklich nur ser2net läuft und sonst nichts anderes, ein Upgrade.
Und mhhh, ja er steckt an einen Fritz Mesh repeater über LAN Kabel dran.
Ich schau heut nochmal bisschen, und wenn ich es nicht hinbekomme, schaue ich mich nach einen anderen und am besten orginal CUL um.
So komm ich denk nicht weiter.
Mich macht es nur eben stutzig warum geht's mit der culfw ohne Probleme Tagelang. Und mit der a-culfw eben nicht.
Da komm ich an meine Grenzen.
Na mal schauen
Wenn es nur ein firmware-Problem sein sollte (kann auch mal vorkommen): mal Signalduino antesten? (die 433-er Geräte muß man dazu nach meiner bisherigen Erfahrung nicht umkonfigurieren).
Einen original-CUL würde ich persönlich nicht mehr kaufen. Wenn es ein neues netzwerkfähiges Interface sein soll, würde ich den MapleCUN ins Rennen werfen... Der kann zum praktisch gleichen Preis viel mehr und du mußt keinen Pi mehr warten ;) .
Da höre ich jetzt das erste mal davon .. MapleCUL
.. Selbstbau fällt für mich aus, da ich grobmotoriker bin und keine Lötkenntnisse habe etc.
Jetzt hab ich mal danach geschaut, gibt ja schon viel verschiedenes fertig zu kaufen.
Weiß nicht ob ich das hier darf, einen Link aus der Bucht zu schicken (Ansonsten bitte löschen)
https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.de%2Fulk%2Fitm%2F113408219215
(https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.de%2Fulk%2Fitm%2F113408219215)
So was in der Art?
Sieht für mich wie ein normaler nano CUL aus und nicht wie in fhem Wiki er beschrieben wird.
Jein.
Es gibt ihn auch mit 4 Transceivern und (v.a.!) Netzwerkanschluß, dazu zwei UART-Anschlüsse, siehe https://wiki.fhem.de/wiki/MapleCUN (https://wiki.fhem.de/wiki/MapleCUN).
Kann sein, dass der dann mit vernünfitgen Antennen etwas teuerer wäre, Angebote gibt es in der Regel auch hier im Forum (Marktplatz/Güter), da ist in der Regel der Preis halt Material+Unkosten. Wenn du "irgendwo" kaufst, ist der support leider häufig mau, und "Schrumpfschlauch"-Varianten hatten wir leider beim "Selbstbau-CUL" einige, die nicht richtig funktioniert hatten, weil diese Schrumpfköpfe falsche FTDI's untergeschoben erhalten hatten oder sich Spannungsteiler gespart, oder oder oder...
Wo ich das schreibe: Suche nach deiner FTDI-Nummer ergibt u.a. https://softsolder.com/2016/09/02/counterfeit-ftdi-usb-serial-adapter-roundup/ (https://softsolder.com/2016/09/02/counterfeit-ftdi-usb-serial-adapter-roundup/)
Vielleicht magst du deinem freundlichen Verkäufer auf's Dach steigen!?!
Nachtrag (aus http://www.starlino.com/ftdi-chip-real-of-fake-how-to-spot-a-fake-rt232r-rt232rl-and-others.html):
ZitatWhy it is important to spot a fake FTDI fake and why I am posting it ? Because it can ruin your day like it did for me ! Fake FTDI chips are unreliable especially at higher baud rates and you may be pulling your hair troubleshooting your project while the problem is in fact a cheap fake chip.
Ja und so ein CHIP wird da bestimmt bei dem Link aus der Bucht verbaut sein.. ich lasse da die Finger von und schau hier mal im Forum unter Güter ..ansonsten mach ich mal ein Kaufgesuch.
Vielen Dank dir für deine Mühen
Edit: ein Upgrade vom raspberry ändert auch nichts. Ist so. Liegt dann wohl doch am CUL
Zitat von: moerte am 18 Dezember 2018, 14:10:19
[...] so ein CHIP wird da bestimmt bei dem Link aus der Bucht verbaut sein..
Nö!
Nur zur Klarstellung, da liegt ein Mißverständnis vor.
Ein Arduino Nano besteht intern aus 2 größeren IC's, nämlich dem eigentlichen Microprozessor (ATMega32) und einem USB-Seriell-Wandler, hier vermeintlich von FTDI.
Der Maple (bzw. der STM32F103) macht das USB-Interfacing selbst. Die Firmware als MapleCUx stellt dabei sogar 3 logische USB-Ports bereit, einen für die eigentliche CUL-Funktion (die 4 gestackten Transceiver), und je einen für die beiden UART (mit denen man dann z.B. ein Pi-Homematic-PCB betreiben kann).
Steht aber eigentlich (in Kurzform) auch in dem Wiki-Artikel ;) .