Hauptmenü

Zwei CULS gleichzeitig betreiben

Begonnen von Kusselin, 02 Januar 2017, 09:56:51

Vorheriges Thema - Nächstes Thema

Kusselin

Hallo Zusammen und ein gutes Neues,

ich habe z.Zt. ein CUL 868 in Betrieb udn möchte jetzt noch parallel ein CUL 433 in betrieb nehmen.

Meine Fragen:

1. Muss ich zum flashen des CUL 433 den CUL 868 abziehen komplett vom PI? (das kommt aus Wiki und hier im Forum nicht so raus)
2. Die Firmware ist die gleiche wie beim 868 auf der CUL Homepage (akt. vers. 1.66)?

Über ne Rückinfo herzlichen Dank

Kussel

KölnSolar

1. Ich flashe nach wie vor mit Flip auf dem Windows-Rechner. Hat noch nie Probleme gemacht.
2. Da hast Du doch schon früher ne Menge Infos zu bekommen. ::) Nimmst Du die Standard-culfw, ist es das selbe hex-File. Willst Du etwas mehr aus dem 433er herausholen, nimmst Du die a-culfw. Die ist je Frequenz unterschiedlich.
Gutes neues Jahr, Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Kusselin

Zitat von: KölnSolar am 02 Januar 2017, 10:23:30
1. Ich flashe nach wie vor mit Flip auf dem Windows-Rechner. Hat noch nie Probleme gemacht.

O.K. ich habe den ersten CUL 868 über die Konsole geflasht. Mir gehts jetzt drum..wenn der zweite 433 kommt und ich diesen auch wieder per Konsole flashe, muss der 868er dann während des Flashvorgangs raus ausm USB Port am PI?

Zitat von: KölnSolar am 02 Januar 2017, 10:23:30
2. Da hast Du doch schon früher ne Menge Infos zu bekommen. ::) Nimmst Du die Standard-culfw, ist es das selbe hex-File. Willst Du etwas mehr aus dem 433er herausholen, nimmst Du die a-culfw. Die ist je Frequenz unterschiedlich.
Gutes neues Jahr, Markus
Ja danke Dir fü die Wünsche..das gleiche Dir auch!!
Ja das die Standard Firm ne andere ist wie die aculf ist mir auch klar. meine Frage ist aber: Wenn ich die Standard nehme gibt es keinen Unterschied (entweder für 868 oder 433)...das merkt die Firm beim flashen dann richtig?

Gruss

Beta-User

Zitat von: Kusselin am 02 Januar 2017, 12:42:29
Mir gehts jetzt drum..wenn der zweite 433 kommt und ich diesen auch wieder per Konsole flashe, muss der 868er dann während des Flashvorgangs raus ausm USB Port am PI?
Auch von meiner Seite ein gutes Neues!
Der CUL muß dann nicht raus, wenn Du das flash-Ziel korrekt angibst...

Zitat von: Kusselin am 02 Januar 2017, 12:42:29
Ja das die Standard Firm ne andere ist wie die aculf ist mir auch klar. meine Frage ist aber: Wenn ich die Standard nehme gibt es keinen Unterschied (entweder für 868 oder 433)...das merkt die Firm beim flashen dann richtig?
Du mußt auch hinterher die CUL auseinanderhalten, damit die jeweils die richtigen Befehle bekommen. Infos dazu, v.a. auch zur Benennung und Einbindung gab es hier im Forum in der letzten Woche unter praktisch demselben Titel, bitte suchen (falls Du einen weiteren Kauf-CUL hast und keinen Eigenbau). Kurzfassung: Dann besser selber compilieren, vorher durch Änderung des Sourcecodes den CUL eindeutig benennen und ihn dann per "by-id" eindeutig einbinden. Das dürfte ähnlich auch für die a-culfw zutreffen (da gleiche HW-Basis, wenn Original-Busware-CUL).
Für 433 würde ich aber trotzdem nochmal über einen Signalduino nachdenken...

Grüße, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Kusselin

Hallo Beta-User..danke Dir auch :-)

ich werde den jetzigen CUL über "Serial ID" einbinden. (habe mir jetzt schon den zweiten CUL 433 bestellt).

wenn ich so vorgehe dürfte ich nichts falsche machen, ansonsten bitte berichtigen!!

1. Raspi ist on und der erste CUL 868 ist eingesteckt.
2. Putty öffnen - sich anmelden als Root
3. folgenden Befehl absetzen: ls -l /dev/serial/by-id
4. dann kommt eine Ausgabe in Putty z.B so: lrwxrwxrwx 1 root root 13 Jan  9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
5. dann gebe ich in der Eingabezeile in FHEm z.B. folgendes ein (man muss halt darauf achten was beim Auslesen angezeigt wird...das dann kopieren z.B.
define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134
6. Nun sollte mein erster CUL immer richtig zugeordnet werden..richtig?

Das gleiche mache ich nach dem flashen meines zweiten CULS !!

Gruss

KölnSolar

Genau. Und der 433er wird sich mit der id ....CUL433... zu Wort melden.
ZitatWenn ich die Standard nehme gibt es keinen Unterschied (entweder für 868 oder 433)...
ZitatNimmst Du die Standard-culfw, ist es das selbe hex-File.
::)
Zitatdas merkt die Firm beim flashen dann richtig?
Ja.
Bisschen mehr Mut  ;)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Kusselin

Zitat von: KölnSolar am 02 Januar 2017, 15:36:11
Genau. Und der 433er wird sich mit der id ....CUL433... zu Wort melden.

Aber einbinden muss ich den 433 CUL dann auch noch so...also mit den Befehl über Putty und der FHEM Kommandoleiste...richtig?

Zitat von: KölnSolar am 02 Januar 2017, 15:36:11
Bisschen mehr Mut  ;)
Ja, da gebe ich Dir recht...den könnte ich ab und an mehr haben!!!

Trotzdem Danke dir

Beta-User

Zitat von: KölnSolar am 02 Januar 2017, 15:36:11
Bisschen mehr Mut  ;)
+1!
Wie bereits geschrieben: wenn richtig was kaputt gehen kann, steht es in der Regel deutlich da!

Ergänzend:
- die <FHTID> ist hoffentlich aus dem Beispiel kopiert und zwischenzeitlich im Produktivsystem geändert?!?
- Da Du vorrangig 433-er Signale empfangen willst: Das ist der Kern der Weiterentwicklung der a-culfw... Vielleicht solltest Du in Erwägung ziehen, diese wenigstens testweise zu verwenden 8), wenn Du schon dem Signalduino keine Chance geben willst ;D.

Solange Du das nicht 3x am Tag über Jahre machst, ist das mit dem Umflashen unproblematisch ::), und wie (sofern sich die USB-Kennung überhaupt ändert) die Gerätedef "by-id" hin- und hergewechselt werden kann, weißt Du ja jetzt auch ;).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

KölnSolar

ZitatGerätedef "by-id"
ist beim busware-CUL unabhängig von der Firmware. Bei (manchen ?) Selbstbaugeschichten sieht das glaub ich anders aus...
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

Zitat von: KölnSolar am 02 Januar 2017, 15:59:40
ist beim busware-CUL unabhängig von der Firmware. Bei (manchen ?) Selbstbaugeschichten sieht das glaub ich anders aus...

@Markus
Dazu hat mich vor kurzem Telekatz anders aufgeklärt: Gerade bei den Busware-CUL's wird die ID mit in die Firmware geschrieben, da der USB-Wandler dort Teil des Atmel-Microcontrollers selbst ist (anders als bei den Nanos, die für USB-seriell ein Fremdprodukt anderer Hersteller verwenden). Details dazu hier.

Ist nur eine Vermutung, aber: da der CC1101 nicht aktiv mitteilt (?), für welche Frequenz er optimiert wurde, könnte es sein, dass man dem CUL nach dem Flashen erst mal beibringen muß, was er für ein CUL ist und er dann erst (diese Info ins EEPROM schreibt und) sich fortan korrekt ins USB-System einklinkt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Kusselin

#10
Zitat von: Beta-User am 02 Januar 2017, 15:48:09
- die <FHTID> ist hoffentlich aus dem Beispiel kopiert und zwischenzeitlich im Produktivsystem geändert?!
Jepp du meinst die "1234"....am Ende, die habe ich geändert, aber so wie du sagtest mit Zahlen 0-9 und A-F gehts net :-(
also mit den Zahlen schon aber in Kombi z.B. 2304AC (6-stellig) funzt net !!

Zitat von: Beta-User am 02 Januar 2017, 15:48:09
- Da Du vorrangig 433-er Signale empfangen willst: Das ist der Kern der Weiterentwicklung der a-culfw... Vielleicht solltest Du in Erwägung ziehen, diese wenigstens testweise zu verwenden 8), wenn Du schon dem Signalduino keine Chance geben willst ;D.
Genau das will ich also 433er Signale empfangen.
Und zur Verdeutlichung. Wenn ich die Originale Firm beim 433er CUL draufspiele kann ich nur 433Mhz senden aber nicht empfangen, sondern dann nur 868 Mhz empfangen...deshalb die aculfw die beides kann also senden und empfangen von 433Mhz....richtig?

Zitat von: Beta-User am 02 Januar 2017, 15:48:09
wenn Du schon dem Signalduino keine Chance geben willst ;D.
Wer sagt das??? :-) Kann ich mir doch immer noch besorgen

Zitat von: Beta-User am 02 Januar 2017, 15:48:09
und wie (sofern sich die USB-Kennung überhaupt ändert) die Gerätedef "by-id" hin- und hergewechselt werden kann, weißt Du ja jetzt auch ;).
das habe ich nicht kapiert...sorry! :-[

Beta-User

Zitat von: Kusselin am 02 Januar 2017, 16:29:01
Jepp du meinst die "1234"....am Ende, die habe ich geändert, aber so wie du sagtest mit Zahlen 0-9 und A-F gehts net :-(
also mit den Zahlen schon aber in Kombi z.B. 2304AC (6-stellig) funzt net !!
OK, habe eben nochmal in die Commandref gesehen, ich habe da etwas durcheinandergeworfen:
Wenn Du kein FHT machen willst, solltest Du das auf 0000 stellen und dann zusätzlich ein attr hmId <hmID> (<HMID>: 6-stellige HEX) machen. Asche auf mein Haupt...

Zitat von: Kusselin am 02 Januar 2017, 16:29:01
Und zur Verdeutlichung. Wenn ich die Originale Firm beim 433er CUL draufspiele kann ich nur 433Mhz senden aber nicht empfangen, sondern dann nur 868 Mhz empfangen...deshalb die aculfw die beides kann also senden und empfangen von 433Mhz....richtig?
Die a-culfw "kennt" nach meiner Kenntnis einfach mehr 433-er Protokolle und ist daher "besser" im Sinne von aktueller. Auch die "reguläre" FW kann einen (großen?) Teil der Protokolle in beide Richtungen.

Zitat von: Kusselin am 02 Januar 2017, 16:29:01
Wer sagt das??? :-) Kann ich mir doch immer noch besorgen
Na ja, ob ein Signalduino neben einem CUL433 noch viel Sinn macht, weiß ich nicht; der 2. CUL deckt vermutlich Deinen Bedarf ab, und die schnelle Bestellung der teuren Lösung klang nicht nach Experimentierfreude ;)...

Zitat von: Kusselin am 02 Januar 2017, 16:29:01
das habe ich nicht kapiert...sorry! :-[
Na ja, Du hast die Anleitung zitiert, nach der man jeweils den aktuellen "by-id"-Namen rausfinden kann. Wird jetzt ein "by-id"-definiertes Gerät umbenannt (bzw. meldet sich unter einer anderen USB-ID), kann man mit der Anleitung auch eine vorhandene "by-id"-Definition anpassen; es ist ganz genau dasselbe...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

KölnSolar

ZitatDazu hat mich vor kurzem Telekatz anders aufgeklärt: Gerade bei den Busware-CUL's wird die ID mit in die Firmware geschrieben
Korrekt. Ich meinte damit auch: solange man nicht an der board.h selber rumbastelt  ;)

ZitatIst nur eine Vermutung, aber: da der CC1101 nicht aktiv mitteilt (?), für welche Frequenz er optimiert wurde, könnte es sein, dass man dem CUL nach dem Flashen erst mal beibringen muß, was er für ein CUL ist
Deshalb schrieb ich
Zitatbusware-CUL
. Der ist per Hardware gekennzeichnet. Mit einem zusätzlichen Widerstand(an Pin ?) ist es ein 433er. Ohne diesen ein 868er. Das wird dann in der firmware abgefragt.

ZitatWenn ich die Originale Firm beim 433er CUL draufspiele kann ich nur 433Mhz senden aber nicht empfangen, sondern dann nur 868 Mhz empfangen...deshalb die aculfw die beides kann also senden und empfangen von 433Mhz....richtig?
Das it sooo nicht richtig. Selbstverständlich empfängt der 433CUL auch 433MHz. 868 MHZ wird überhaupt nicht empfangen. Die a-culfw hat lediglich zusätzliche 433er-Protokolle implementiert, die die culfw (noch) nicht erkennt.
anders ausgedrückt
ZitatDie a-culfw "kennt" nach meiner Kenntnis einfach mehr 433-er Protokolle und ist daher "besser" im Sinne von aktueller. Auch die "reguläre" FW kann einen (großen?) Teil der Protokolle in beide Richtungen.
Ich hoffe wir haben Dich mit dem Fortgeschrittenen-Exkurs nicht zusätzlich verwirrt  ???
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

Zitat von: KölnSolar am 02 Januar 2017, 17:23:00Ich hoffe wir haben Dich mit dem Fortgeschrittenen-Exkurs nicht zusätzlich verwirrt  ???
Schließe mich an :).

Und um Nachfragen vorzubeugen: Man kann also die FW einfach so flashen, wie sie ist, stecken 2 CUL dran, muß man halt den richtigen Port angeben...

Zitat von: KölnSolar am 02 Januar 2017, 17:23:00
Der ist per Hardware gekennzeichnet. Mit einem zusätzlichen Widerstand(an Pin ?) ist es ein 433er. Ohne diesen ein 868er. Das wird dann in der firmware abgefragt.
THX für die Info, wieder was gelernt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Faber38

ich habe einen 868 und einen 433 Mhz CUL ...
wenn ich flashe bleiben immer beide dran.Eben halt nur den richtigen Port benennen.

define MyCUL868 CUL /dev/ttyACM0 1234
attr MyCUL868 hmId ABCABC
attr MyCUL868 icon cul_868
attr MyCUL868 rfmode HomeMatic
attr MyCUL868 room USBAnschluss,wohnzimmer
define MyCUL433 CUL /dev/ttyACM1 1134
attr MyCUL433 icon cul_cul
attr MyCUL433 room USBAnschluss,wohnzimmer


Ich hab den 433er für
clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT

laufen um den 868er für
clients     
:CUL_HM:HMS:CUL_IR:STACKABLE_CC:

ich bin mit dieser Lösung super zufrieden.