[FHZ] Multi-FHZ/CUL

[rudolfkoenig]

                                                   

(Ich habe mal einen neuen Thread angefangen, damit der Subject auch
was mit dem Inhalt zu tun hat).

> Gibt's auch jetzt eigentlich 'ne Möglichkeit, einen CUL, der an
> einem entfernten Rechner hängt, FHEM über's Netz zugänglich zu
> machen?

Ja, socat ist dein Freund. Mit dem neuesten 00_CUL.pm kann man
wahrscheinlich einen socat sparen, das habe ich aber nicht getestet.

Ansonsten habe ich verstanden, dass viele Leute gerne "Empfang ueber
alle" haben wollen -> werde es also wieder einbauen.

"Senden ueber alle" finde ich nicht gut, aber man koennte es als was
optionales einbauen, wahrscheinlich mit einem speziellen Attribut pro
Geraet. Macht aber nur Sinn, falls die CUL's repeater Signale
koennen.  "Manuell" geht das auch jetzt schon "fhem-only" mit trigger:
dazu muss man fuer die Zweit-CUL's Schattengeraete mit korrekter
Zuordnung anlegen.
CUL sollte auf jedem Fall "repeater"-Signale und evtl. einen
kompletten Repeater-Mode lernen.

Fuer starke Stromverbraucher verwende ich auch den on-for-timer modus,
und sende das Signal zweimal, via shell-skript 1 Sekunde versetzt. Ein
off wird  auch gesendet, da on-for-timer mit groesseren Zeitwerten
zunehmend ungenau wird.

> Wie sieht dann die Zuordnung der einzelnen Devices zu den jeweiligen
> FHZ/CUL/CUN Devices aus? Geht das mittels dem IODev Attribut?

Das ist z.Zt. notwendig wenn man save verwendet. Beim start ordnet
sich ein "logisches" Geraet (FS20MS, etc) dem letzten
"physikalischen" (FHZ/CUL) in der Konfigurationsdatei zu. Da beim
"save" alle "physikalischen" als erstes rausgeschrieben werden,
aendert sich die Zuordnung.

Gruss,
  Rudi
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>> Gibt's auch jetzt eigentlich 'ne Möglichkeit, einen CUL, der an
>> einem entfernten Rechner hängt, FHEM über's Netz zugänglich zu
>> machen?
>
> Ja, socat ist dein Freund. Mit dem neuesten 00_CUL.pm kann man
> wahrscheinlich einen socat sparen, das habe ich aber nicht getestet.

Hmm. Auf dem entfernten Rechner läuft via xinetd:

socat -ly -lh GOPEN:/dev/ttyACM0,raw,echo=0,crnl -

Auf dem FHEM-Rechner läuft:

socat PTY,link=/dev/cul2 TCP:$host:$port &

Angesprochen wird dieser CUL in FHEM mit:

define CUL2 CUL /dev/cul2

Prinzipiell scheint es zu funktionieren, allerdings mag FHEM diesen
CUL nicht:

2009.09.08 13:32:01 3: CUL opening CUL device /dev/cul2
2009.09.08 13:32:02 3: CUL opened CUL device /dev/cul2
2009.09.08 13:32:02 5: CUL/RAW: V 1.24 CUL868

2009.09.08 13:32:05 5: CUL/RAW: V 1.24 CUL868

2009.09.08 13:32:08 5: CUL/RAW: V 1.24 CUL868

2009.09.08 13:32:11 1: Not an CUL device, receives for V:  Timeout reading answer for get Version
2009.09.08 13:32:11 3: Not an CUL device, receives for V:  Timeout reading answer for get Version

Mit telnet bekomme ich (seit ich ",raw,echo=0,crnl" beim ent-
fernten Rechner im xinetd-Aufruf hinzugefügt habe) bei einem "V"
ein "V 1.24 CUL868".

Hilft mir bitte jemand auf die Sprünge, ich habe nichts zu "fhem
socat" per Google gefunden, und auch zu socat selbst sind die
Beispiele dürftig

Danke & Ciao,
         kai


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

                                                   

> Hilft mir bitte jemand auf die Sprünge, ich habe nichts zu "fhem
> socat" per Google gefunden, und auch zu socat selbst sind die
> Beispiele dürftig


Ich habe auch mal socat installiert, und habe auf dem gleichen Rechner
folgendes getan:
xterm1: socat GOPEN:/dev/ttyACM0 TCP-LISTEN:9999
xterm2: socat PTY,link=/tmp/cul2 TCP:localhost:9999
fhem config:define CUL CUL /tmp/cul2 0000
-> funktioniert prima.

Alternative (nur mit aktuellen 00_CUL.pm)
xterm1: socat GOPEN:/dev/ttyACM0 TCP-LISTEN:9999
fhem config:define CUL CUL localhost:9999 0000
-> funktioniert auch prima.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:

> Ich habe auch mal socat installiert, und habe auf dem gleichen Rechner
> folgendes getan:
> xterm1: socat GOPEN:/dev/ttyACM0 TCP-LISTEN:9999
> xterm2: socat PTY,link=/tmp/cul2 TCP:localhost:9999
> fhem config:define CUL CUL /tmp/cul2 0000
> -> funktioniert prima.

Ja, in der Tat, so funktioniert's auch über's Netz. Dreck, macht mir wohl
xinetd einen Strich durch die Rechnung? Plöd, und 'ne inittab gibt's auch
nimmer, scheiß Fortschritt

Mit

( while [ 1 ] ; do /usr/bin/socat -ly -lh GOPEN:/dev/ttyACM0 TCP-LISTEN:$port ; sleep 1 ; done )

auf dem Server (muß noch bißchen aufgehübscht werden -- leider
beendet sich socat ja nach jedem Schließen des Abfragesockets) und

socat PTY,link=/dev/cul2 TCP:$host:$port &

auf der FHEM-Box klappt's jetzt auch bei mir. Danke!

Allerdings:

2009.09.08 17:04:59 5: CUL/RAW: /T331500BA00FF

2009.09.08 17:04:59 3: CUL1: T331500BA00 -74.5
2009.09.08 17:04:59 5: CUL1 dispatch 810a04xx0909a00133150000ba00
2009.09.08 17:05:00 5: CUL/RAW: /T331500BA00E6

2009.09.08 17:05:00 4: CUL2: T331500BA00 -87
2009.09.08 17:05:00 5: CUL2 dispatch 810a04xx0909a00133150000ba00
2009.09.08 17:05:06 5: CUL/RAW: /T0A5500BA001A

2009.09.08 17:05:06 3: CUL1: T0A5500BA00 -61
2009.09.08 17:05:06 5: CUL1 dispatch 810a04xx0909a0010a550000ba00
2009.09.08 17:05:06 5: FHZ/RAW: 810c04cc09 (Unparsed: )
2009.09.08 17:05:06 5: FHZ/RAW: 09a0010a550000ba00 (Unparsed: 810c04cc09)
2009.09.08 17:05:06 5: FHZ1 dispatch 810c04cc0909a0010a550000ba00
2009.09.08 17:05:06 4: FHT FHT_Test2 actuator: lime-protection

Beide CULs und meine FHZ empfangen den FHT eines Nachbarn -- aber
IIRC standen früher da mal Werte, was ist denn "lime-protection"?



2009.09.08 17:07:45 5: CUL/RAW: /E0206202E0A0C000C002D

2009.09.08 17:07:45 3: CUL1: E0206202E0A0C000C00 -51.5
2009.09.08 17:07:45 5: CUL1 dispatch E0206202E0A0C000C00
2009.09.08 17:07:45 5: CUL_EM EM2: CNT: 32 CUM: 2606  5MIN: 12  TOP: 12
2009.09.08 17:07:45 4: CUL_EM EM2: CNT: 32 CUM: 133.678  5MIN: 0.120  TOP: 0.120

Der CUL im EG empfängt den EMEM im Wohnzimmer ...

2009.09.08 17:07:59 5: CUL/RAW: /K21458348DE

2009.09.08 17:07:59 4: CUL2: K21458348 -91
2009.09.08 17:07:59 5: CUL2 dispatch K21458348
2009.09.08 17:08:01 5: CUL/RAW: /E0205AE08841000150043

2009.09.08 17:08:01 4: CUL2: E0205AE088410001500 -40.5
2009.09.08 17:08:01 5: CUL2 dispatch E0205AE088410001500
2009.09.08 17:08:18 5: CUL/RAW: /K1146224815

2009.09.08 17:08:18 3: CUL1: K11462248 -63.5
2009.09.08 17:08:18 5: CUL1 dispatch K11462248
2009.09.08 17:08:18 4: CUL_WS WS300 S300TH S300TH_2: T: 24.6  H: 48.2

... der CUL im OG den im Arbeitszimmer, wie es sein soll -- aber
warum wird der in FHEM nicht mehr ausgewertet? Dito für das WS300-
Gerät, welches ich offensichtlich oben (CUL2) aber nicht unten
empfange?

Definiert sind:

setdefaultattr room Arbeit
define EM1 CUL_EM 5 0.01
attr EM1 model EMEM
[...]
setdefaultattr room Essen
define Essz_TH CUL_WS 1
attr Essz_TH model S300

setdefaultattr room Huette
define Huette_TH CUL_WS 3
attr Huette_TH model S300

setdefaultattr room Kammer
define Kammer_TH CUL_WS 6
attr Kammer_TH model S300

setdefaultattr room Wohnen
define EM2 CUL_EM 6 0.01
attr EM2 model EMEM
define Terrarium_TH CUL_WS 5
attr Terrarium_TH model S300
[...]
setdefaultattr room Keller
define Keller_TH CUL_WS 8
attr Keller_TH model S300

setdefaultattr
define EM3 CUL_EM 7 0.01
attr EM3 model EMEM
define EM4 CUL_EM 8 0.01
attr EM4 model EMEM
[...]
define S300TH_2 CUL_WS 2
attr S300TH_2 model S300
define S300TH_4 CUL_WS 4
attr S300TH_4 model S300
define S300TH_7 CUL_WS 7
attr S300TH_7 model S300

==> Ich müßte alle möglichem EMEM und alle möglichen S300TH
definiert haben, mithin sollten entsprechend doch auch die
von CUL2 empfangenen verarbeitet werden?

Definiert wird CUL2 vor CUL1, damit Sendebefehle, sofern ich
das richtig verstanden habe, im Wohnzimmer/EG rausgehen (im OG
habe ich derzeit nur Sensoren, keine Aktoren). Ciao,
         kai


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

                                                   

> Beide CULs und meine FHZ empfangen den FHT eines Nachbarn -- aber
> IIRC standen früher da mal Werte, was ist denn "lime-protection"?

Fluch des Sommers.
Einmal die Woche werden alle Ventile komplett geoeffnet und wieder geschlossen.
Wenn die danach nicht mehr geoffnet werden muessen, dann sendet der FHT statt
"actuator XXX" weiterhin die "lime-protection" Telegramme. Workaround: FHT auf
29 Grad stellen, und dann wieder zurueck. In der Hoffnung dass bei Dir in der
Wohnung nicht so warm ist, sonst hilft es nicht


> ... der CUL im OG den im Arbeitszimmer, wie es sein soll -- aber
> warum wird der in FHEM nicht mehr ausgewertet? Dito für das WS300-
> Gerät, welches ich offensichtlich oben (CUL2) aber nicht unten
> empfange?

Siehe die lustige Multi-FHZ Diskussion -> schau mal welchen IODev die Geraete
haben. Abhilfe ist entweder "attr IODev" fuer jeden Device oder "define CUL2"
an "richtiger" Stelle (d.h. vor den Geraeten, die CUL2 als IODev haben
sollen), und save nicht verwenden.

  Gruss,
    Rudi

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

                                             

Hallo,

ein Punkt, der in den letzten Wochen schon einmal aufgeworfen wurde, und
  in dieser Diskussion noch nicht genannt wurde, ist die
"Luftverschmutzung", die auftritt, wenn viele Geraete im Einsatz sind.
Bei mir senden 9 FHT80, 2 HMS100TF, 1 KS300 und 3 EMs. Das fuehrt
haeufiger zu Kollisionen mit dem Effekt, dass nicht alle Rolladen auf
Befehl tatsaechlich auf- oder zufahren oder abends ein Teil des Gartens
nicht gewaessert wird. Wenn nun _jeder_ Befehl repeater-mehrfach
gesendet wird, reduziert das die verfuegbare Bandbreite weiter.
Allerdings wird vermutlich in den meisten Installationen den
FS20-Aktions-Kommandos Prioritaet vor den FHT/KS/HMS/EM-Informationen
einzuraeumen sein.

Senden/Empfangen ueber alle Steuergeraete ist meiner Ansicht nach von
untergeordneter Bedeutung, da bei adaequater Positionierung der
CULs/CUNs/FHZs und Zuordnung der Geraete zu diesen per IODev das Problem
der Reichweite/Empfangsstaerke geloest werden kann.

Bleibt das Problem der Kollisionen. Ein CUL als "dummer" Repeater ist
m.E. entbehrlich, da stattdessen besser gleich eine bandbreitenschonende
intelligente Zuordnung wie im obigen Abschnitt vorgenommen wird.

Hilfreich waere sicherlich, den Repeat Count je Zielgeraet individuell
setzen zu koennen (die Terrariumlampe bekommt 10x gesagt, dass sie
ausgehen soll). Das duerfte relativ schlank und ohne grundlegene
Eingriffe in die Architektur machbar sein. Es wuerde vermutlich mein
Rolladenproblem mildern, da diesem aufgrund der Funktionsweise des
FS20RSU nicht mit Mehfachsenden beizukommen ist. Dito Dimmen.

Nachdenken koennte man auch noch ueber eine Kollisionserkennung: CUL1
sendet und CUL2 prueft, ob es die von CUL1 gesendeten Daten empfangen
hat. Wenn CUL2 nichts gehoert hat, heisst das aber leider nicht, dass
auch das angesprochene Geraet nichts mitbekommen hat.

Gruesse,
Boris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

info-r@koeniglich.de wrote:
>> Beide CULs und meine FHZ empfangen den FHT eines Nachbarn -- aber
>> IIRC standen früher da mal Werte, was ist denn "lime-protection"?
>
> Fluch des Sommers.

Dann heizt mein unbekannter Nachbar also derzeit nicht

>> ... der CUL im OG den im Arbeitszimmer, wie es sein soll -- aber
>> warum wird der in FHEM nicht mehr ausgewertet? Dito für das WS300-
>> Gerät, welches ich offensichtlich oben (CUL2) aber nicht unten
>> empfange?
>
> Siehe die lustige Multi-FHZ Diskussion -> schau mal welchen IODev die Geraete
> haben. Abhilfe ist entweder "attr IODev" fuer jeden Device oder "define CUL2"
> an "richtiger" Stelle (d.h. vor den Geraeten, die CUL2 als IODev haben
> sollen), und save nicht verwenden.

Danke, klar lag's am IODev CUL1 für die Geräte im OG, nach einem
"attr IODev CUL2" klappt's nun. *sigh* Ich hatte aus den
Logmeldungen geschlossen, daß jedes empfangene Telegramm auch aus-
gewertet würde. Das Folgende dann imho ganz schön, warum ich den
multiplen Empfang (und entsprechende Auswertung ) gut fände:

2009.09.08 18:09:35 3: CUL1: K21947248 -75.5
2009.09.08 18:09:35 4: CUL2: K21947248 -89.5
2009.09.08 18:18:23 4: CUL2: K21887249 -91.5
2009.09.08 18:24:15 3: CUL1: K21857249 -78
2009.09.08 18:27:11 3: CUL1: K21833250 -76
2009.09.08 18:27:11 4: CUL2: K21833250 -88
2009.09.08 18:30:07 3: CUL1: K21813250 -75.5
2009.09.08 18:30:07 4: CUL2: K21813250 -88
2009.09.08 18:33:03 4: CUL2: K21808250 -89
2009.09.08 18:35:59 4: CUL2: K21788250 -91.5
2009.09.08 18:44:47 4: CUL2: K21743251 -91.5

(Dieser Sensor ist derzeit CUL1 zugeordnet, da jener eigentlich
deutlich näher dran ist ...)
         kai

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Moin,

Dr. Boris Neubert wrote:
> ein Punkt, der in den letzten Wochen schon einmal aufgeworfen wurde, und
>   in dieser Diskussion noch nicht genannt wurde, ist die
> "Luftverschmutzung", die auftritt, wenn viele Geraete im Einsatz sind.
> Bei mir senden 9 FHT80, 2 HMS100TF, 1 KS300 und 3 EMs. Das fuehrt

Bei mir sind es derzeit 7 S300TH (Plan: , 2 (Plan: 4) EM, 1 FMS;
dazu senden/lauschen dann 1 FHZ, 2 CUL und lauschen derzeit 5 FS20-
Geräte. Irgendein Nachbar hat mind. 2 FHTs im Einsatz ...

> haeufiger zu Kollisionen mit dem Effekt, dass nicht alle Rolladen auf
> Befehl tatsaechlich auf- oder zufahren oder abends ein Teil des Gartens
> nicht gewaessert wird. Wenn nun _jeder_ Befehl repeater-mehrfach
> gesendet wird, reduziert das die verfuegbare Bandbreite weiter.

Ja, das sehe ich auch mit Sorge; siehe Logauszug, der schon andeutet,
daß auch bei mir schon Signale teilweise am einen oder anderen Empfän-
ger nicht ankommen. Hinzu kommen die IT+-Geräte, die ja in deutlich
kleinerem Intervall senden sollen ...

Für Energie-Schaltvorgänge überlege ich daher derzeit, auf die Power-
line-Technik zu gehen (Allnet-Geräte), die Statusrückmeldung ermög-
lichen sollen.

> Allerdings wird vermutlich in den meisten Installationen den
> FS20-Aktions-Kommandos Prioritaet vor den FHT/KS/HMS/EM-Informationen
> einzuraeumen sein.
>
> Senden/Empfangen ueber alle Steuergeraete ist meiner Ansicht nach von
> untergeordneter Bedeutung, da bei adaequater Positionierung der
> CULs/CUNs/FHZs und Zuordnung der Geraete zu diesen per IODev das Problem
> der Reichweite/Empfangsstaerke geloest werden kann.

Letztlich diskutieren wir hier eigentlich ein Luxusproblem, denn ohne
die dankenswerte Entwicklung von CUL & Co. stellte sich die Frage kaum,
bei den prohibitiven Kosten einer FHZ

Beim Empfang -- der keine zusätzliche Bandbreite frißt, sondern als
Abfallprodukt einfach so geschieht -- würde ich eine Empfänger unab-
hängige Auswertung als Default für sinnvoll erachten, aber mit Ein-
grenzungsoption (z. B. wenn der Nachbar auch S300TH einsetzt ...).
Letztlich müßte IODev wohl für Senden und Empfangen getrennt werden --
parallele Sendung, davon bin ich schon fast überzeugt , macht nur
selten Sinn, paralleler Empfang hingegen schon.

So, und jetzt mach' ich mich mal auf die Suche nach socat für die
Fritz!Box, als Basis für verteilte CULs ...
         kai


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-