Zufallsgenerator: Mehrere CUL

Begonnen von Guest, 01 September 2012, 15:03:59

Vorheriges Thema - Nächstes Thema

Guest

Originally posted by: <email address deleted>

Tag zusammen,

Zur Zeit habe ich folgendes Phänomen:  Ich betreibe zwei CUL an einer
FritzBox 7390. Die erste CUL verwende ich für FS20, eine zweite für
HomeMatic. Dabei ist die HomeMatic CUL neu, die FS20 CUL relativ alt (so
alt, dass HomeMatic noch nicht dafür unterstützt wird). Wenn nun die
FritzBox (neu)gestartet wird, mappt das AVM Linux die USB Geräte auf
/dev/ttyACM[0-1]. Leider ist dieses mapping nicht deterministisch, was zur
Folge hat, dass die Mappings plötzlich verdreht sind und ich keine
HomeMatic Kommandos mehr senden / empfangen kann. Dieses
nicht-deterministische Mapping resultiert wohl auch darauf, dass beide CULs
(trotz unterschiedlicher Version) die gleiche Geräte und die gleiche Vendor
ID haben (sagt lsusb).

Hat jemand von euch eventuell das selbe Problem und schon eine Lösung
dafür? Mir fällt gerade nicht ein, wie man überhaupt unterscheiden kann,
welche CUL an welchem tty hängt.

Viele Grüße,
Matthias

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

rudolfkoenig

                                                   

> Mir fällt gerade nicht ein, wie man überhaupt unterscheiden kann, welche CUL
> an welchem tty hängt.

Eine gute Loesung habe ich auch nicht, nur drei ungetestete Ideen:

- Evtl gibt es eine Moeglichkeit auf dem FB ein Device Abhaengig vom Steckplatz
  zu benennen, auf einem Linux mit udev geht sowas sicher.

- man koennte culfw/Devices/CUL/board.h fuer CUL_V2 so modifizieren, dass
  alle benoetigten features reinpassen, indem man nicht benoetigte entfernt.
  Wichtig: nach dem Uebersetzen mit
    make TARGET=CUL_V2 MCU=at90usb162 mostly_clean build size
  darf die Summe von text+data 12288 nicht ueberschreiten, und bss muss auch
  unter 400 bleiben.

- in fhem koennte man ein notify fuer global:INITIALIZED bauen, der das
  Ergebnis einer get CUL_0 version (oder aehnliches) auswertet, das HM-Cul
  nochmal auf HM-Mode setzt, und das IODev aller betroffenen Geraete passend
  setzt, z.Bsp fuer HM Geraete:
    attr subType=.* IODev $hmCul
  Alle nicht-hm Geraete muesste man mit einem user-Attribut versehen, damit das
  Setzen der IODev auch so einfach geht.

Alle drei Methoden sind unbefiredigend. Das Kaufen einer CUL-V3/V4 ist
wahrscheinlich wirtschaftlicher.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Oder man nimmt stattdessen CUNO, und hat dann noch den Vorteil
ortsunabhängig im Haus zu sein.

Gruß Wolfram


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Tobias

                                                   

Kann man keine udev-rules definieren auf ner Fritze? Wenn ja isses einfach
über die serialNumber des CUL´s

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter