LAN2SER Gateway-Daemon? Hab's vergessen *grummel*

[M_I_B]

Moin...

gestern Abend hat es die SD meines TRX- Raspi gerissen (drei SCC auf einem per LAN angebundenem PI2b); Backup war natürlich über ein Jahr alt 

Also bin ich heute mal eben beigegangen und habe die aktuelle BUSTER-LITE draufgeschmirgelt... So weit, so gut...

Was mir aber ums Verrecken nicht mehr einfällt ist, was ich da seinerzeit als Daemon für die Anbindung an die FHEM Hauptinstanz installiert hatte... Jajaja, Notizen machen... Mache ich jetzt auch... Versprochen 


Also...
Von der Hauptinstanz habe ich den ersten SCC wie folgt angesprochen:

Code Auswählen Erweitern

define SCC1 CUL 192.168.1.192:2000 9874

Also IP- Adresse, Port und (ich meine) PIN


Kann da zufällig wer auf das passende Gegenstück zurückschließen?
Oder gibt es eine bessere Option, ohne viel umschreiben zu müssen?

[Beta-User]

Code Auswählen Erweitern

define SCC1 CUL 192.168.1.192:2000 9874

Also IP- Adresse, Port und (ich meine) PIN

Commandref sagt: <FHTID>

Ansonsten dürfte da auf dem TRX-Raspi ser2net oder socat gelaufen sein.

Für ser2net könnte neben der manpage dazu noch https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Variante_mit_ser2net helfen?

[M_I_B]

 


Vielen lieben Dank! ser2net war's... Ist mir einfach nicht eingefallen 

[M_I_B]

... ok, das läuft wieder ...

aBär:
Der erste SCC wird als "opened" angezeigt, die beiden weiteren SCC als "disconnected". Also irgendwie fehlt da noch was, vermutlich in der ser2net.conf... Da steht z.Z. schlicht und ergreifend folgendes:

Code Auswählen Erweitern

2000:raw:0:/dev/ttyAMA0:115200 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE

Das tut ja wohl auch, da der erste SCC geöffnet wurde...

[RaspiLED]

Nee läuft nicht, sonst wäre der erste initialized!
Probiere mal 9600 Baud Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...

[M_I_B]

... bist Du Dir sicher? Ich glaube nicht...


HM-LAN -> STATE: opened, state: opened / Gerät funktioniert

SCC1 -> STATE: opened, state: opened / Gerät funktioniert
SCC2 -> STATE: Defined, state: disconnected / Gerät funktioniert nicht
SCC3 -> STATE: Defined, state: disconnected / Gerät funktioniert nicht

(nach einem Neustart steht da nun immer Defined an Stelle von disconnected)

Ich hatte jetzt auch schon diverse Baudraten durch bis hinunter zu den von Dir vorgeschlagenen 9600; keinerlei Änderung, auch nicht nach jeweiligem Neustart TRX-PI und FHEM- Hauptinstanz

[M_I_B]

... ok ...

Mit Minicom 38400 8n1 auf ttyAMA0 kann ich mit V, *V resp **V die drei SCC erreichen. Das sollte also soweit vollkommen ok sein von der Seite her (Hardware, Baudrate etc.)

Bin irgendwie ratlos ...

Auf Seiten der Hauptinstanz habe ich nichts verändert. Der Vollständigkeit halber hier mal die Config, wie sie seit Jahren so da drin steht (naja, MAX ist vergangenes Jahr dazu gekommen):

Code Auswählen Erweitern

### HM- LAN einbinden ###
define UFO1 HMLAN 192.168.1.198:1000
attr UFO1 alias UFO1 HM 868MHz
attr UFO1 event-on-change-reading .*
attr UFO1 group Transceiver
attr UFO1 hmId F10000
attr UFO1 hmLanQlen 1
attr UFO1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr UFO1 room System

### Initialisierung SCC's ###
define SCC1 CUL 192.168.1.192:2000 0706
attr SCC1 alias SCC1 IT 433MHz
attr SCC1 event-on-change-reading .*
attr SCC1 group Transceiver
attr SCC1 rfmode SlowRF
attr SCC1 room System

define SCC2 STACKABLE_CC SCC1
attr SCC2 alias SCC2 MX 868MHz
attr SCC2 event-on-change-reading .*
attr SCC2 group Transceiver
attr SCC2 rfmode MAX
attr SCC2 room System
define Max_Eco CUL_MAX 121212
attr Max_Eco IODev SCC2
attr Max_Eco group Transceiver
attr Max_Eco room System

define SCC3 STACKABLE_CC SCC2
attr SCC3 alias SCC3 HM 868MHz
attr SCC3 event-on-change-reading .*
attr SCC3 group Transceiver
attr SCC3 hmId F10000
attr SCC3 rfmode HomeMatic
attr SCC3 room System

### Virtuelle CCU bauen füt HM ###
define VCCU CUL_HM F10000
attr VCCU .mId FFF0
attr VCCU IODev SCC3
attr VCCU IOList SCC3,UFO1
attr VCCU alias Virtuelle CCU
attr VCCU group Virtuelle CCU
attr VCCU model CCU-FHEM
attr VCCU room System
attr VCCU subType virtual
attr VCCU webCmd virtual:update

### HM- LAN bei Overload überlisten ###
define UFO_reboot DOIF ([UFO1] eq "overload") ({HMLAN_SimpleWrite($defs{'UFO1'}, "Y05")})
attr UFO_reboot do always


[M_I_B]

* Problem gelöst *

Wo auch immer der Fehler her gekommen ist...

Ich habe ein Update des kompletten OS gemacht, nach Neustart ein Update von FHEM selber und seit dem laufen alle SCC wieder wie gewohnt...

Irgend etwas hatte sich da wohl auf der Hauptinstanz verhaspelt, was durch das Update wieder ins Lot gerückt wurde...


Thema durch und ich noch mehr graue Haare als vorher 

[M_I_B]

.. Noch ein Nachtrag:

Gestern Abend habe ich noch auf TRX- Seite mit verschiedenen Baudraten experimentiert. Dabei konnte ich ein merkwürdiges Verhalten feststellen:

• Baudrate geändert
• TRX Neustart OS
• Keine Kommunikation vom Master zum TRX
• shutdown restart Master
• keine Kommunikation vom Master zum TRX
• Master Neustart OS
• Kommunikation wieder hergestellt

Offensichtlich verhaspelt sich bei Änderung der Baudrate auf der Clienseite irgendwie der Master. Ich konnte das hier in jedem einzelnen Versuch (13 Versuche) jedesmal reproduzieren, habe aber keinen blassen Schimmer, an welcher Stelle es hakt...

Vielleicht hilft wem anders diese Feststellung ja mal aus der Not...