FHEMWiki - Benutzerbeiträge [de]

Creating Plots

2022-01-19T10:19:46Z

Mikezulugolf: /* Placeholders */ changed tiny typo

{{Randnotiz|RNTyp=[g|Info]|RNText=Note: "Create SVG Plot" in detail view of ''FileLog'' type devices allows direct configuration in FHEMWEB frontend. This is in more detail described in [[Plots_erzeugen|.gplot editor]] (german) and might be helpfull for learning the syntax. For more advanced options and generalized syntax, you'll have to directly edit the files as described here.}}
= Howto create a PGM2/SVG plot - Introduction =
Output using the PGM2 engine is generated through .gplot files. The name is historical and today files can be generated using gnuplot or SVG graphics. This howto lists the most important aspects of generating a SVG configuration file.

Each graphic generated by FHEM is described by one configuration file. It is currently not possible to generate one page with several graphics from one configuration file.

Taking a high level view for each plot the following is needed:

* Data from a logfile (create it using the FileLog facility)
* Plot configuration (.gplot) file knowing about the internal structure of the logfile
* Association between the FileLog and the plot configuration (using the "logtype" attribute in the FileLog and the LINK in the WebLink object, also see comments below)
* Weblink representing the plot itself
= FileLog objects =
Digging into the more murky details, first thing is the creation of the FileLog object:

* The FileLog object is always associated with a physical device (but see comments below)
* The creation of a FileLog object together with the corresponding logfile is automatic if the "autocreate" attribute is set in FHEM (it is set by default)
* Manual creation is also possible and requires a statement like:
<nowiki>
define FL_KS550 FileLog /var/log/fhem/KS550_%Y.log KS550:T:.*
define FileLog_ZwSt_1 FileLog /opt/fhem/var/log/ZwSt_1_%Y.log ZwSt_1
define FL_ZwSt_ALL FileLog /opt/fhem/var/log/ZwSt_ALL_%Y.log ZwSt_.*deviceMsg.*BidCoS_RF.*
</nowiki>
* Be it manual or automatic: the definition of a FileLog object determines (through the regular expression) which of the output lines of FHEM end up in the logfile

= Plot definition =
Once the logfile is accumulating data, the plot configuration itself is needed. There is no object for this, but plain .gplot files in the share/FHEM directory are used by the system. A good start is to copy an existing one and modify it.

On a side note: if you create your own files instead of using the ones already delivered with FHEM, stick to the convention of prepending them with a "my". Files of pattern "my*" are guaranteed not to be overwritten during FHEM updates (or so Rudi promised me).

The following entries are recognized in a SVG context:

* #FileLog holds the information which data need to be extracted from the logfile. See below for details.
* Set commands: title, ylabel, y2label, yrange, y2range, ytics, y2tics, teminal (only "size" parameter is recognized)
* Plot command: see below for details
== Placeholders ==
It is possible to use placeholders in the .gplot files, which will then be replaced by information provided by the actual WebLink attributes listed below. This has the advantage that you can define one .gplot file and re-use it for several devices, changing size, title and lables accordingly instead of maintaining several separated files.

* <OUT> : only relevant for gnuplot
* <SIZE>: attr plotsize
* <TL> : attr title. The attribute is eval'ed by perl at runtime, be careful and protect by double quotes if you just want to enter strings. This gives access to all internal FHEM values, though admittedly not straightforward
* <Ln> : attr label. Labels 1-#n can be specified by a double-colon-separated (::) list, see below. This is also eval'ed at runtime, same precautions apply
* <IN> :

In general this is good practice and you should especially consider it if you plan to distribute your .gplot files. Using placeholders f.ex. for the title and all the labels and curve descriptors gives other users the possibility to change them without having to touch the .gplot code.

For extended use of placeholder fuctionality have a closer look on the ''plotreplace'' attribute. Some insctructable examples can be found [[SVG#Beispiele|here]].

== Data Extraction ==
The central piece of the plotfile is the #FileLog line (yes, it must be prepended by a hash!), which is a special command und internally triggers the use of the FileLog "get" function, which extracts data from the logfile. The general syntax is: <nowiki><col>:<regexp>:<default>:<fn></nowiki>
.
* col: selects the column of the line (columns are white space separated, numbering starts at 1)
* regexp: validates/selects the line
* default: default value, if none is present
* fn: function which operates on values, pre-defined or eval'ed, see below

The "get" function will set the following %data values (which can e.g. be used in titles, labels, ...) for each requested column (curve), beggining with <x> = 1:

* min<x>, max<x>
* mindate<x>, maxdate<x>
* avg<x>, cnt<x>
* sum<x>
* currval<x> (last value)
* currdate<x> (last date)
So you can do something like <nowiki>attr <weblink> title "Min $data{min1}, Max $data{max1}, Last $data{currval1}"</nowiki>
Also implemented in this function is code which operates on the data retrieved. This can be specified at the "<fn>" tag. Up till now following functions are impemented:

* int (to cut off % from a number, as for the actuator)
* delta-h / delta-d to get rain/h and rain/d values from continuous data
* And then there is this: the string is evaluated as a perl expression. @fld is the current line splitted by spaces (0-based). So you can do something like $fld[3]/1000 to plot values divided by 1000 or $fld[3]=~"on"?0.9:0.8 to map the 4th field which contains an on/off information into numerical values to be plotted in a graph. Be warned though: this string/perl expression cannot (!) contain any spaces.

For even more details see {{Link2CmdRef|Anker=FileLog}} or the module 92_FileLog.pm.

== Debugging Data Extraction ==
If you do not get the result you are expecting or, worse, no data at all, you may use the debug facility of FHEM to see what the get-command extracts from the logfile. Use telnet to contact FHEM and then use the arguments detailed below ending with the #FileLog argument you are using in the .gplot file:

<nowiki>telnet diskstation 7072
get FileLog_KS550 ?
get FileLog_KS550 - - 2012-01-01 2012-12-31 4::</nowiki>
You should get back the data which you have been asking for, followed by a line holding the .gplot argument. Make sure

* you do not select too much data, this will possibly upset your NAS :-)
* you do select data which really are in the file (beware of year/month changes)
== Plot Commands ==
Once you have extracted the data from the logfile, you need to plot it. There is a plot command which does just that. It has several arguments which you can use:

* axes: not needed by default, but if you want to plot curves which use different y axes, then you must tell the plot command, which y-axis the data should be bound to: "axes x1y1" selects the left, "axes x1y2" the right one
* title: defines the string which is printed in the colour of the curve into the plot. You can (and maybe should) use placeholders like "<Lx>", x being a number
* with: defines how to draw the data. only points, steps, histeps and lines (which acts as a catch all) are currently implemented
* ls: uses CSS definitions, still need to figure out, how this works
* lw: defines the width of a line
== Example ==
A very barebones but functional example of a file using placeholders could be:

<nowiki>set terminal size <SIZE>
set title '<TL>'
set ylabel '<L1>'
set y2label '<L2>'
#FileLog 4:::
plot \
axes x1y1 title '<L3>' with steps lw 2</nowiki>
It implements the placeholders which can be defined by the user through the WebLink attributes later, selects just one column, without regular expression matches, defaults or subsequent data operations and plot is as a steps diagram. In fact even the "axes x1y1" statement could be left out, it would still work.

== Changing text style ==
If you need a text style that is different from the style definition in fhemweb:
Add

<nowiki>text { font-family:Arial, Helvetica, sans-serif; font-size:12px; fill:#xxxxxx;}
text.title {font-family:Arial, Helvetica, sans-serif; font-size:16px; fill:#xxxxxx;}</nowiki>

where #xxxxxx is the color.

== Transparent plots ==
If you need transparent plots, for example in FLOORPLAN, you have to change the following definitions in svg_style.css

Change

<nowiki>.background { fill:#FFFFE7; }</nowiki>
to:

<nowiki>.background { fill:#FFFFE7;fill-opacity: 0; }</nowiki>
Change:

<nowiki>.border { stroke:black; fill:url(#gr_bg); }</nowiki>
to

<nowiki>.border { stroke:black; fill:url(#gr_bg);fill-opacity: 0; }</nowiki>

= WebLink objects =
Once you have created the FileLog object and written the plot specification, there is not much to be done. Click on the reference to the .gplot file in the FileLog section of a device, then click on the link for WebLink creation and then add the attributes you want to have. Put it into a suitable room and you are done.

If you are using placeholders in your .gplot files and after defining your .gplot file you click onto a FileLog "active" link to create the plot itself and get a message like:

<nowiki>XML Parsing Error: mismatched tag. Expected: </L1>.
...
Line Number 51, Column 95:<text x="12" y="80" text-anchor="middle" class="ylabel" transform="rotate(270,12,80)">'<L1>'</text></nowiki>
you can safely ignore it. This is due to the fact, that you are using placeholders in the .gplot definition (which is good, because it favors reuseability) but have not yet defined the corresponding attributes. While annoying, this is not your fault: you can only define attributes once you have a weblink. So click on create weblink and define the attributes you have been using placeholders for. The error message should go away.

The attributes which are generally needed are:

* label: should be defined like "Label 1"::"Label 2". Do not omit double quotes and use them individually for each label. Separator is a double (!) colon. If you ever manage to do away with the double quotes on the axes, please let us all know
* title: Can be as simple as "Some Title" or as complicated as "Temperature $data{currval1} ($data{min1}-$data{max1}), Humidity $data{currval2} ($data{min2}-$data{max2}) @ $data{currdate1}"

= SVG Programs =
The SVG programs can be found in the 98_SVG.pm module. Look for example for the string "histeps". Feel free to adapt and improve. If you ever program a wind rose to plot wind directions, please let me know.

= Details =
What you also should know:

* All data used in a plot come from one (!) file. It is currently not possible to mix data from several files. So make sure that the regular expression of the FileLog object catches everything which you need in one plot
* While it first seems evident that FileLog objects are associated with a given device, this must be mitigated. Imagine that you want to plot the state (and changes) of some socket adaptors (ZwischenStecker) over time. You then need to gather all the data (from several devices) in one file. So instead of define FileLog_ZwSt_1 FileLog /opt/fhem/var/log/ZwSt_1_%Y.log ZwSt_1 you need to specify define FL_ZwSt_ALL FileLog /opt/fhem/var/log/ZwSt_ALL_%Y.log ZwSt_.*deviceMsg.*BidCoS_RF.*
* Be careful when specifying the regular expression which filters the lines for a given logfile. While often it is sufficient to not specify a specific one at all, consider the following case from the Homematic world, where one action results in 4 lines of FHEM output. The switch communicates not only with the CCU, but also with the remote control, issuing 2 lines for each action:
<nowiki>2012-01-01_07:40:23 ZwSt_3 deviceMsg: on (to Dev.WDisp.Kueche)
2012-01-01_07:40:23 ZwSt_3 on
2012-01-01_07:40:26 ZwSt_3 deviceMsg: on (to BidCoS_RF)
2012-01-01_07:40:26 ZwSt_3 on</nowiki>
* Why one needs to specify a logtype (which is nothing else than a plot definition) for the FileLog has always been a mystery to me. It holds no useful information to the object itself and does not influence the way data is written to the associated logfile. Sure, plots need FileLogs, but not the other way round. And since the WebLink contains (again) the name of the plot definition file, the need to define the logtype attribute seems odd. The master himself says regarding this topic: "Ist eine Eigenschaft, die beschreibt, auf welche Art die Daten angezeigt werden koennen. Steht damit direkt neben den Daten, also da wo ich zuerst suchen wuerde. Ist nicht notwendig, aber so kann FHEMWEB ein 'create weblink' anbieten." I have to admit that this link is useful and I use to use it :-)
* If you meet on your way PERL-code snippets in the .gplot files, you can just ignore them safely. They are only used in the gnuplot world, not in SVG anymore. Now you may ask, where you find the corresponding features in SVG? They are hidden in functions defined in the FileLog "get" primitive.

== Documentation ==
Documentation can be found in several places, it is not complete and you need to piece it together:

* http://fhem.de/HOWTO.html#plotting
* http://fhem.de/commandref.html#FileLogget
* http://fhem.de/commandref.html#label

[[Kategorie:HOWTOS]]

Benutzer:Mikezulugolf

2020-02-26T16:11:04Z

Mikezulugolf: /* Über mich */

== Über mich ==
* FHEM Benutzer seit 2010 (mit Tuxradio V1)
** anfänglich nur einige wenige FS20 Schaltaktoren
** dann einige wenige HMS Temperatur/Feuchtesensoren
** Ende 2013: 1-wire Bus, zunächst nur mit einem Dual-S0 Zähler zum Monitoren einer Photovoltaikanlage
** seit März 2014: HMLAN steuert 7 Außenjalousien

* weitere Projekte
** weitere 1-wire Komponenten (DS18B20 Temperatursensoren)
** Türöffnungskontakte, Bewässerungssteuerung (über eigene Queueing-Module), Ansteuerung von Squeezeboxen, Lichtrelais, Heizkreispumpen, Anwesenheitserkennung und -simulation

''Richard''

FileLog

2019-05-10T12:37:51Z

Mikezulugolf: Beispiel für ein ignoreRegexp Attribut

{{Infobox Modul
|ModPurpose=Protokollierung von Fhem-Ereignissen
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=92_FileLog.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])}}

Das Modul [[FileLog]] dient zur Protokollierung von Ereignissen in Fhem. Die Einträge werden in eine einfache Textdatei geschrieben. Zur Protokollierung in eine Datenbank kann alternativ oder auch parallel das Modul [[DbLog]] verwendet werden.

Logdateien sind die Basis für die Erstellung von Diagrammen ([[SVG]]).

== Definition ==
Details in der {{Link2CmdRef|Anker=FileLogdefine}}.

== Attribute ==
Über {{Link2CmdRef|Anker=FileLogattr|Label=Attribute}} lässt sich unter anderem auch festlegen, wie die Archivierung von Logdateien durchgeführt werden soll (Archivierungsbefehl, -pfad sowie Anzahl von Archivgenerationen).

Wenn bestimmte Zeilen nicht in die Logdatei geschrieben werden sollen, ist das Attribut ignoreRegexp hilfreich. Wenn beispielsweise alle Zeilen, die ein "AbCd" oder "CdEf" NICHT geloggt werden sollen, dann wäre
 attr <log-name> ignoreRegexp .*AbCd.*|.*CdEf.* 
das Attribut, das dies ermöglicht.

== Funktionen ==
''FileLog'' bietet Funktionen wie ''reopen'', ''absorb'' und ''get''. Details dazu sind in der {{Link2CmdRef|Anker=FileLogset}} zu finden.

Sofern eine Instanz vom Objekt [[eventTypes]] angelegt ist, bietet die Detailansicht eines FileLog eine komfortable Möglichkeit, die regulären Ausdrücke für den/die Filter zu bearbeiten. Siehe hierzu auch diesen {{Link2Forum|Topic=12557|Message=75436}}.

== Globale Logdatei und "fakelog" ==
Die globale Logdatei (üblicherweise als fhem.log bezeichnet) für Fhem wird mit dem Attribut
:<code>attr global logfile XXX</code>
für das ''global''-Objekt definiert, wobei für ''XXX'' normalerweise <code>./log/fhem-%Y-%m.log</code> verwendet wird.

Um das ''fhem.log'' über das [[FHEMWEB|Web Interface]] anzeigen zu können, ist ein weiterer Eintrag in der [[Konfiguration]] erforderlich, nämlich:
:<code>define Logfile FileLog XXX fakelog</code>
Das ''XXX'' muss '''zwingend''' durch den gleichen Wert ersetzt werden, wie in der Definition des globalen ''logfile'' Attributs, weil anderenfalls unterschiedliche Dateien verwendet werden - mit dem Effekt, dass die über das Web Interface angezeigte Datei nicht die erwarteten Einträge enthält (Details dazu auch in diesem {{Link2Forum|Topic=40041|Message=323315|LinkText=Forenbeitrag}}).

== Werte auslesen ==
Manchmal möchte man Daten aus den Logs abrufen ohne händisch in den Logfiles herumzuwühlen. Dies ist insb. auch dann hilfreich, wenn man eigenen Funktionen, Notifys oder spezielle Plots entwirft, bei denen man auf Logdaten zugreifen möchte.

Grundsätzlich beschrieben ist dies in der {{Link2CmdRef|Lang=de|Anker=FileLog}} und unterscheidet sich minimal (aber entscheidend) von der Struktur bei [[DbLog#Werte_auslesen|DbLogs]].

Hier ein paar Beispiele, was man damit anstellen kann:

* <code>get FileLog_FHT_3a32 - - 2016-10-01 2016-10-03</code> alle Einträge des FileLog_FHT_3a32 vom 01.10.-03.10.2016
* <code>get FileLog_FHT_3a32 - - 2016-10-01_08:00:00 2016-10-01_16:00:00</code> alle Einträge des FileLog_FHT_3a32 von 8-16 Uhr am 01.10.2016
* <code>get FileLog_FHT_3a32 - - 2016-10-01_08:00:00 2016-10-01_16:00:00 4:measured:0:</code> nur die Temperatur-Werte
* <code>{ ReadingsTimestamp("FHT_3a32","state","0") }</code> Timestamp des aktuellen state des FHT_3a32
* <code>{ OldTimestamp("FHT_3a32") }</code> Timestamp des letzten state des FHT_3a32
* <code>{ time_str2num(OldTimestamp("FHT_3a32")) }</code> Timestamp in Sekunden des letzten state des FHT_3a32
* ...
Weitere Beispiele kann man sich gut aus den SVG-Dateien ziehen.

== Links ==
* {{Link2Forum|Topic=40041|Message=323315|LinkText=Forenbeitrag}} zum Thema fhem.log / fakelog

Bewässerungssteuerung

2018-07-04T17:42:44Z

Mikezulugolf: 2 Typos verbessert

<div style="float:right">
{{Infobox Modul
|ModPurpose=Kontrollinstanz der Bewässerungssteuerung
|ModType=contrib
|ModFTopic=22142
|ModForumArea=Unterstützende Dienste
|ModTechName=97_SprinkleControl.pm
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=118 Tobias]
}}
{{Infobox Modul
|ModPurpose=Spezialisiertes Modul zur Bewässerungssteuerung
|ModType=contrib
|ModFTopic=22142
|ModForumArea=Unterstützende Dienste
|ModTechName=98_Sprinkle.pm
|ModOwner=[http://forum.fhem.de/index.php?action=profile;u=118 Tobias]
}}
</div>

Diese Seite beschreibt, wie man intelligent seine Bewässerung steuern kann wenn man Bodenfeuchtesensoren installiert hat.
Weiterhin kann man eine maximale Obergrenze von parallelen Bewässerungen angeben wenn man z.B. von einem Brunnen nur einen begrenzten Mengendurchfluss hat oder das Netzteil nicht alle Ventile gleichzeitig schalten kann.

__INHALTSVERZEICHNIS__

Es wird von folgenden Komponenten ausgegangen:

* Gardena oder Hunter Magnetventile, angesprochen über einen FS20-Aktor (zb. S8M), Homematic-Aktor oder 1wireSchaltaktoren
* Bodenfeuchtesensoren, zb. FS20 BF oder andere (z. B. an einem [[AVR-NET-IO#Analoge_Eing.C3.A4nge_in_FHEM_einbinden|AVR-NET-IO]] oder funkangebunden per [[SWAP#Beispiel:_panStamp_soilmoisture_Sketch_in_FHEM_einbinden|Panstamp]])

==allgemeine Vorbereitungen==
Wird ein 2- oder 8fach 1wire Schaltaktor verwendet, so muss jedes Ventil per [[ReadingsProxy|readingsProxy]] maskiert werden.
Bei jedem FS20 Aktor muss in FHEM das Attribut ''follow-on-for-timer'' auf 1 gesetzt werden.

===Anlegen der Bodenfeuchtesensoren===
Für eines FS20 Sensor: FS20BF
define Bodenfeuchtesensor FS20 34f2 00
attr Bodenfeuchtesensor room Bewässerung

Für eine 1wire Version: einen analogen Sensor (zb. Vegetronix), angeschlossen an einen 4fach A/D Converter DS2450
define Bodenfeuchte OWAD DS2450 03140C000000 60
attr Bodenfeuchte model DS2450
attr Bodenfeuchte room Bewässerung
attr Bodenfeuchte userReadings VWC_A {sprintf("%.0f",(11.6552 * ReadingsVal("$name","A",0)**4 + 7.10835 * ReadingsVal("$name","A",0)**2 - 0.569557) / (ReadingsVal("$name","A",0)**2 + 1))}

Kabelgebundene Vegetronix Bodenfeuchtesensoren können per [[SWAP#Beispiel:_panStamp_soilmoisture_Sketch_in_FHEM_einbinden|Panstamp-Anbindung]] auch funkbasiert arbeiten.

===Bewässerungsventile definieren===
Falls für jedes Magnetventil ein eigenes Device existiert. Zb. bei Nutzung von eines SM8/SM4/FS20ST/HM-LC-SW4-DR
define Bewaesserung_Ventil1 FS20 2305 51
attr Bewaesserung_Ventil1 model fs20st
attr Bewaesserung_Ventil1 room Bewässerung

Wird die Bewässerungssteuerung mittels 1Wire betrieben, so verfügt 1 Device (i.d.R DS2406/DS2408/DS1413) über 2 oder 8 Ports.
An folgendem Device hängen die physischen Bewässerungsventile. Dieses muss natürlich an die eigenen Gegebenheiten angepasst werden :)
define Schalter_rechts OWSWITCH DS2408 xxxxxxxxxxxxxx
attr Schalter_rechts IODev 1wireBus
attr Schalter_rechts model DS2408
attr Schalter_rechts room Bewässerung
attr Schalter_rechts stateS .

Zusätzlich das readingsProxy-Device für den Port A
define Bewaesserung_Ventil1 readingsProxy Schalter_rechts:A
attr Bewaesserung_Ventil1 room Bewässerung
attr Bewaesserung_Ventil1 setFn {"output A $CMD"}
attr Bewaesserung_Ventil1 setList on off
attr Bewaesserung_Ventil1 valueFn {($VALUE eq "ON.")?"OFF":"ON"}
attr Bewaesserung_Ventil1 webCmd on:off

===Module bereitstellen===
Als nächstes sind die benötigten Module aus dem FHEM SVN contrib Verzeichnis in das FHEM-Verzeichnis zu kopieren:
* [http://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/97_SprinkleControl.pm 97_SprinkleControl.pm]
* [http://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/98_Sprinkle.pm 98_Sprinkle.pm]

==Definitionen==
Pro Bewässerung bzw Bewässerungsventil ist eine SprinkleInstanz zu definieren:

define MySprinkle1 Sprinkle Bewaesserung_Ventil1 Bodenfeuchte:VWC_A +00:05:00;
attr MySprinkle1 Sprinkle_OnTimeSec 30;
attr MySprinkle1 Sprinkle_SensorThreshold 55;
attr MySprinkle1 room Bewässerung;
attr MySprinkle1 webCmd Auto:An:Aus:Toggle:Disable;

Die Timerangabe kann periodisch z.B. +00:05:00 alle 5min (wie im Beispiel oben) oder einmalig am Tag z.b. 04:00:00 für 4:00 Uhr eingestellt werden. Nach Ablauf des Timers wird überprüft, ob die Bodenfeuchte im Reading ''VWC_A'' kleiner als der Wert im Attribut ''Sprinkle_SensorThreshold'' ist und gegebenenfalls ein ''on-for-timer'' Befehl auf den Aktor ''Bewaesserung_Ventil1'' abgesetzt. Die Dauer der Beregnung bzw. des on-for-timers richtet sich nach dem Attributwert ''Sprinkle_OnTimeSec''.

Es sind folgende ''Set'' Befehle möglich:
* '''Disable''' Deaktivierung. Erst ein erneuter Disable-Befehl aktiviert die Instanz wieder. Während einer Deaktivierung werden keine anderen Befehle akzeptiert
* '''An''' Manuelles Starten eines Bewässerungsprozesses
* '''Aus''' Manuelles Stoppen eines Bewässerungsprozesses
* '''Toggle''' Je nach aktuellem Zustand wird ein Bewässerungsprozess gestartet oder gestoppt
* '''Auto''' Der Auto-Modus ist nur verfügbar, wenn ein Bodenfeuchtesensor angegeben ist sowie die Attribute ''Sprinkle_OnTimeSec'' und ''Sprinkle_SensorThreshold'' angegeben sind. 
Der erste Klick auf ''Auto'' versetzt die Instanz in den AutoModus. Jeder folgende Klick startet einen Bewässerungsprozess im AutoModus - Je nach Zustand der Bodenfeuchte wird nun bewässert oder nicht.

==weitere Spezialfälle==
Ist die Anzahl der parallelen Bewässerungsprozesse zu begrenzen, so ist eine übergeordnete Kontrollinstanz zu definieren. Beispielsweise durch einen maximalen Wasserdurchfluss den ein Brunnen bedienen kann.

define MySprinkleControl SprinkleControl;
attr MySprinkleControl SprinkleControl_MaxParallel 1;
attr MySprinkleControl room Bewässerung;

Hiermit wird maximal ein Bewässerungsprozess zugelassen. Alle folgenden werden in eine Queue eingereiht und nacheinander abgearbeitet. 
Die vorher definierte SprinkleInstanz ist nun noch mit der Kontrollinstanz zu verbinden.

attr MySprinkle1 SprinkleControl SprinkleControl;

Mit einer einzelnen SprinkleInstanz kann man die Auswirkung noch nicht erkennen, dazu müssen weitere SprinkleInstanzen für weitere Bewässerungsventile angelegt werden

==Links==
Forumsthread zum Modul: {{Link2Forum|Topic=22142}}

[[Kategorie:Code Snippets]]

HM-ES-PMSw1-Pl Funk-Schaltaktor 1-fach mit Leistungsmessung

2017-08-03T18:46:27Z

Mikezulugolf:

{{Infobox Hardware
|Bild=HM-ES-PMSw1-PI-Frontansicht.jpg
|Bildbeschreibung=Frontansicht
|HWProtocol=HomeMatic
|HWType=[[HomeMatic Type powerMeter|powerMeter]]
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=6
|HWVoltage=230V
|HWPowerConsumption=<0,6W
|HWPoweredBy=Netz
|HWSize=59 x 123 x 40mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}


[[HM-ES-PMSw1-Pl Funk-Schaltaktor 1-fach mit Leistungsmessung|HM-ES-PMSw1-Pl]] ist ein [[HomeMatic]] Funk-Schaltaktor in Zwischenstecker-Ausführung, der über die Schaltfunktion hinaus auch Informationen über den aktuellen Verbrauch der angeschlossenen Verbraucher sowie über die anliegende Spannung und Netzfrequenz liefert. Dieser Aktor ist seit dem 20.12.2013 verfügbar.

Ein Gerät mit gleichem Funktionsumfang ist als [[HM-ES-PMSw1-DR Hutschienen-Schaltaktor mit Leistungsmessung|HM-ES-PMSw1-DR]] für die Hutschienenmontage verfügbar.

[[Datei:HM-ES-PMSw1-PI-Seitenansicht.jpg|thumb|HM-ES-PMSw1-PI Seitenansicht]]

== Features ==
HomeMatic Funk-Schaltaktor mit Leistungsmessung für zwei Funktionsbereiche:
* Schalten von angeschlossenen Verbrauchern (Schaltkanal)
* Messen von Spannung, Strom, Wirkleistung, Frequenz und Energieverbrauch (Messkanal)
* Automatische Schalten von angelernten Aktoren beim Über- oder Unterschreiten von definierten Schwellwerten (Sensorkanäle)

Der Schaltkanal kann angeschlossene Verbraucher oder angelernte HomeMatic Aktoren ein- bzw. ausschalten.
Der Messkanal verfügt über eine Messfunktion und Empfangs- sowie Übertragungsmöglichkeit von Messdaten (z.B. Spannung, Strom, Wirkleistung, Frequenz und Energieverbrauch bis 3680 Watt/16 A). Die Messdaten werden je nach Verbraucherverhalten in Abständen von einigen Sekunden bis mehreren Minuten übertragen, der Sendezyklus kann durch verschiedene Register konfiguriert werden (Änderungsschwellwerte). Des weiteren kann er - in Abhängigkeit von definierbaren Schwellwerten (Über- / Unterschreitung) - andere Aktoren schalten.

'''Technische Daten:'''
* Spannungsversorgung: 230 V/50 Hz
* Stromaufnahme: 16 A max.
* Leistungsaufnahme Ruhebetrieb: < 0,6 W
* Max. Schaltleistung: 3680 W (ohmsche Last)
* Schutzart: IP 20
* Relais: Schließer
* Schaltzyklen: 50.000 bei cosφ=1
* Abmessungen (B x H x T): 59 x 123 x 40 mm
* Gewicht: 165 g (ohne Netzstecker)
* Messauflösung Leistung: 0,01 W
* Messbereich Leistung: 0–3.680 W
* Messgenauigkeit Leistung: 1 % ±0,03 W
* Messauflösung Strom: 1 mA
* Messbereich Strom: 0–16 A
* Messgenauigkeit Strom: 1 % ±1 mA
* Messauflösung Spannung: 0,1 V
* Messbereich Spannung: 200–255 V
* Messgenauigkeit Spannung: 0,5 % ±0,1 V
* Messauflösung Frequenz: 0,01 Hz
* Messbereich Frequenz: 48,72–51,27 Hz
* Messgenauigkeit Frequenz: 0,1 % ±0,01 Hz

(Angaben ohne Gewähr)

== Hinweise zur Inbetriebnahme und Installation ==
Der PMSw1 funktioniert "out-of-the-box", nachdem er an FHEM angelernt (gepairt) worden ist.

Das [[Pairing (HomeMatic)|Pairing]] sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

== Betrieb mit FHEM ==
Der PMSw1 verfügt über insgesamt 6 Kanäle (HM-Jargon: channels), von denen der Schaltkanal (Kanal 1) und der Messkanal (Kanal 2) in FHEM primär genutzt werden. Die Kanäle 3 - 6 sind zur Konfiguration der Schaltvorgänge [[Peering (HomeMatic)|gepeerter]] Aktoren bei Änderungen des Leistungsverbrauchs (Kanal 3), des Stromverbrauchs (Kanal 4), der elektrischen Spannung (Kanal 5) oder der Frequenz (Kanal 6). Diese Kanäle können ausschließlich über Register konfiguriert werden.

=== Channels (Kanäle) 01 bis 06 ===
==== Channel 01 (_Sw) ====
Der eigentliche Schaltkanal, über den die am PMSw1 eingesteckten Verbraucher ein- und ausgeschaltet werden können.

Log-Datei des Kanals:

<Datum>_<Zeit> HMPMSW_01_Sw set_on
<Datum>_<Zeit> HMPMSW_01_Sw level: 100 %
<Datum>_<Zeit> HMPMSW_01_Sw pct: 100
<Datum>_<Zeit> HMPMSW_01_Sw deviceMsg: on (to HMLAN1)
<Datum>_<Zeit> HMPMSW_01_Sw timedOn: off
<Datum>_<Zeit> HMPMSW_01_Sw set_off
<Datum>_<Zeit> HMPMSW_01_Sw level: 0 %
<Datum>_<Zeit> HMPMSW_01_Sw pct: 0
<Datum>_<Zeit> HMPMSW_01_Sw deviceMsg: off (to HMLAN1)
<Datum>_<Zeit> HMPMSW_01_Sw timedOn: off

==== Channel 02 (_Pwr) ====

Der Messkanal des PMSw1, über den die momentane Netzspannung, die Frequenz (in Hz), die aktuellen Verbrauchswerte (Last, Watt) sowie die seit Inbetriebnahme umgewandelte Leistung ("Verbrauch", Wh) usw. an die Zentrale (hier FHEM) übermittelt werden.

Log-Datei des Kanals:

<Datum>_<Zeit> HMPMSW_01_Pwr energy: 153.2
<Datum>_<Zeit> HMPMSW_01_Pwr power: 90.92
<Datum>_<Zeit> HMPMSW_01_Pwr current: 427
<Datum>_<Zeit> HMPMSW_01_Pwr voltage: 233.4
<Datum>_<Zeit> HMPMSW_01_Pwr 50: -
<Datum>_<Zeit> HMPMSW_01_Pwr boot: on
<Datum>_<Zeit> HMPMSW_01_Pwr energy: 153.8
<Datum>_<Zeit> HMPMSW_01_Pwr power: 80.85
<Datum>_<Zeit> HMPMSW_01_Pwr current: 384
<Datum>_<Zeit> HMPMSW_01_Pwr voltage: 232.2
<Datum>_<Zeit> HMPMSW_01_Pwr 50: -
<Datum>_<Zeit> HMPMSW_01_Pwr boot: on
<Datum>_<Zeit> HMPMSW_01_Pwr energy: 157.5
<Datum>_<Zeit> HMPMSW_01_Pwr power: 86.41
<Datum>_<Zeit> HMPMSW_01_Pwr current: 409
<Datum>_<Zeit> HMPMSW_01_Pwr voltage: 232.6
<Datum>_<Zeit> HMPMSW_01_Pwr 50: -
<Datum>_<Zeit> HMPMSW_01_Pwr boot: on

==== Channel 03 (_SenPwr) ====

Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis des '''momentanen Leistungsverbrauchs''' (Überschreitung oder Unterschreitung) der angeschlossenen Verbraucher. Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen aufgrund des '''momentanen Leistungsverbrauches''' ein Schaltbefehl gesendet werden soll.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenPwr R-txThrLoPwr: 200 W
<Datum>_<Zeit> HMPMSW_01_SenPwr R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenPwr R-txThrHiPwr: 100 W
<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenPwr R-ledOnTime: 0.5 s

Dieser Kanal dient nur zum Auslesen und Setzen der Register für die Schaltautomaik und stellt daher keine Readings oder speziellen Kommandos zur Verfügung.

==== Channel 04 (_SenI) ====
Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis des '''momentanen Stromverbrauchs''' (Überschreitung oder Unterschreitung) der angeschlossenen Verbraucher. Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen aufgrund des '''momentanen Stromverbrauchs''' ein Schaltbefehl gesendet werden soll.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenI R-txThrLoCur: 20 mA
<Datum>_<Zeit> HMPMSW_01_SenI R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenI R-txThrHiCur: 10 mA
<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenI R-ledOnTime: 0.5 s

Dieser Kanal dient nur zum Auslesen und Setzen der Register für die Abschaltautomatik und stellt daher keine Readings oder speziellen Kommandos zur Verfügung.

==== Channel 05 (_SenU) ====
Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis der aktuell anliegenden '''elektrischen Spannung''' (Überschreitung oder Unterschreitung). Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen auf Basis der '''elektrischen Spannung''' ein Schaltbefehl durchgeführt werden soll.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenU R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenU R-txThrLoVlt: 24 V
<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenU R-txThrHiVlt: 22 V
<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenU R-ledOnTime: 0.5 s

==== Channel 06 (_SenF) ====
Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis der '''Frequenz''' (Überschreitung oder Unterschreitung) der anliegenden Spannung. Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen auf Basis der '''Frequenz''' ein Schaltbefehl durchgeführt werden soll.

Die Abschaltung erfolgt dann selbstständig durch den Aktor.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenF R-txThrHiFrq: 49.8 Hz
<Datum>_<Zeit> HMPMSW_01_SenF R-txThrLoFrq: 50.2 Hz
<Datum>_<Zeit> HMPMSW_01_SenF R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenF R-ledOnTime: 0.5 s

Dieser Kanal dient nur zum Auslesen und Setzen der Register für die Abschaltautomatik und stellt daher keine Readings oder speziellen Kommandos zur Verfügung.

=== Beispielkonfiguration ===
Ein Master-Slave-Beispiel aus dem {{Link2Forum|Topic=32840|Message=253040|LinkText=Forum}} um einen HM-ES-PMSw1-Pl mit einem HM Aktor zu [[Peering (HomeMatic)|peeren]]:

Es gibt vier Sensorkanäle: Leistung (03), Strom (04), Spannung (05) und Frequenz (06). Wenn in Abhängigkeit vom Strom geschaltet werden soll, wird der Strom-Komparator-Channel mit einem Aktor gepeert.

set HM-ES-PMSw1-Pl_Senl peerChan 0 hm_aktor set

Dann wird der Komparator eingestellt. Hier werden die Events konfiguriert die der Komparator an den Aktor senden soll. Eine Übersicht gibt es mit <code>get regList</code>:

list: register | range | peer | description
1: cndTxCycAbove | literal | | cyclic trigger if level is above cndTxDecAbove options:on,off
1: cndTxCycBelow | literal | | cyclic trigger if level is below cndTxCycBelow options:on,off
1: cndTxDecAbove | 0 to 255 | | level for cndTxCycAbove
1: cndTxDecBelow | 0 to 255 | | level for cndTxCycBelow
1: cndTxFalling | literal | | trigger if falling options:on,off
1: cndTxRising | literal | | trigger if rising options:on,off
1: ledOnTime | 0 to 1.275s | | LED ontime
1: sign | literal | | signature (AES) options:on,off
1: transmitTryMax | 1 to 10 | | max message re-transmit
1: txThrHiCur | 0 to 16000mA | | threshold low current
1: txThrLoCur | 0 to 16000mA | | threshold high current
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off

Zuerst musst entschieden werden, was wie geschaltet werden soll: bei welchem Strom soll ein-/ausgeschaltet werden. Bei positiver oder negativer Flanke. Sollen die Schaltbefehle permanent wiederholt werden, oder nur bei Änderung kommen und welche Schaltwerte sollen bei den Ereignissen gesendet werden.

Beispiel, 2 Events erzeugen:
#wenn i von unter 10mA nach über 100mA wechselt, wird ein Event mit dem Wert 200 gesendet (daraus machen wir später im Aktor ein on).
#wenn i von über 100mA nach unter 10mA wechselt, wird ein Event mit dem Wert 0 gesendet (daraus machen wir später im Aktor ein off).

Schaltschwellen definieren:

txThrHiCur 100
txThrLoCur 10

Cyclisches Senden abschalten:

cndTxCycAbove off
cndTxCycBelow off

Beide Schaltflanken auswerten, positiv soll anschalten, negativ soll ausschalten:

cndTxFalling on
cndTxRising on

und zum Schluss die Werte setzen, die der Messsensor bei den Events übermitteln soll. Zur Erinnerung: positive Flanke => 200 und negative Flanke => 0:

cndTxDecAbove 200
cndTxDecBelow 0

Danach wird im Aktor festgelegt, was beim Eintreffen von den Werten 0,200 geschehen soll.

=== event Monitor ===
<Bitte ergänzen>

=== fhem.log Auszug ===

2013.12.29 19:06:11.957 3: CUL_HM Unknown device CUL_HM_HM_ES_PMSw1_Pl_24A920, please define it
2013.12.29 19:06:11.976 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920 CUL_HM 24A920 A1A5B840024A9200000001400AC4B455130393635383038513F0100
2013.12.29 19:06:11.994 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920
2013.12.29 19:06:16.879 3: Device CUL_HM_HM_ES_PMSw1_Pl_24A920 added to ActionDetector with 000:10 time
2013.12.29 19:06:16.889 3: CUL_HM pair: CUL_HM_HM_ES_PMSw1_Pl_24A920 powerMeter, model HM-ES-PMSw1-Pl serialNr KEQ0965808
2013.12.29 19:06:16.998 3: Device CUL_HM_HM_ES_PMSw1_Pl_24A920 added to ActionDetector with 000:10 time
2013.12.29 19:06:17.905 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw CUL_HM 24A92001
2013.12.29 19:06:17.909 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw
2013.12.29 19:06:18.906 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr CUL_HM 24A92002
2013.12.29 19:06:18.909 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr
2013.12.29 19:06:19.906 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr CUL_HM 24A92003
2013.12.29 19:06:19.909 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr
2013.12.29 19:06:20.906 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI CUL_HM 24A92004
2013.12.29 19:06:20.910 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI
2013.12.29 19:06:21.907 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU CUL_HM 24A92005
2013.12.29 19:06:21.974 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU
2013.12.29 19:06:22.096 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920 getConfig
2013.12.29 19:06:22.917 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF CUL_HM 24A92006
2013.12.29 19:06:22.921 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF
2013.12.29 19:06:28.968 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw statusRequest
2013.12.29 19:06:29.980 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU getConfig
2013.12.29 19:06:33.990 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF getConfig

=== fhem.cfg ===
<pre>define CUL_HM_HM_ES_PMSw1_Pl_24A920 CUL_HM 24A920
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 .devInfo 3F0100
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 .stc 51
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 IODev LANCUL
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 actCycle 000:10
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 actStatus alive
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 autoReadReg 4_reqStatus
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 expert 2_full
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 firmware 1.4
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 peerIDs
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 room CUL_HM
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 serialNr KEQ0965808
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 subType powerMeter
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 webCmd getConfig

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw CUL_HM 24A92001
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr CUL_HM 24A92002
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr peerIDs
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr CUL_HM 24A92003
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI CUL_HM 24A92004
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU CUL_HM 24A92005
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF CUL_HM 24A92006
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF room CUL_HM
</pre>

=== Loggen von Werten ===
Leider werden die Verbauchswerte nicht automatisch geloggt, das von FHEM angelegte Log sammelt nur Informationen des Haupt-Devices.

Damit hier auch die Verbrauchs- und Stromwerte mitgeloggt werden, muss man dies dem Log des Haupt-Device (bevorzugt per WebInterface) hinzufügen.

Am Ende sollte die entsprechende Definition wie folgt aussehen:
:<code>define FileLog_Keller.Waeschetrockner FileLog ./log/Keller.Waeschetrockner-%Y.log Keller.Waeschetrockner|Keller.Waeschetrockner_Pwr:.*</code>

Die Devicenamen sind natürlich an die vorliegenden Gegebenheiten anzupassen.

=== Plots/Grafiken ===
Hier ein Beispielplot für den Channel 02 (Pwr):

[[Datei:HM-ES-PMSw1-PI cut.jpg|Plot des HM-ES-PMSw1-PI (Channel 02)]]

Inhalt der zugehörigen gplot-Datei (SVG_FileLog_HMPMSW_01_Pwr_1.gplot):

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Energie"
set y2label "Power"

#FileLog 4:HMPMSW_01_Pwr.energy\x3a::
#FileLog 4:HMPMSW_01_Pwr.power\x3a::

plot "<IN>" using 1:2 axes x1y1 title 'Energie' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Power' ls l1 lw 1 with lines

und die Definitionen dafür beim Device (fhem.cfg):

define SVG_FileLog_HMPMSW_01_Pwr_1 SVG FileLog_HMPMSW_01_Pwr:SVG_FileLog_HMPMSW_01_Pwr_1:CURRENT

== Tipps ==
Um dafür zu sorgen, dass nach einem Stromausfall der Aktor den Schaltausgang von sich aus auf "An" stellt (Default ist "Aus"), kann man wie folgt vorgehen:

# Device auf übliche Weise mit FHEM pairen
# Interne Peers/Register für FHEM aktivieren <code>set <deviceName> regSet intKeyVisib visib</code>
# Erneutes getConfig auf das Device durchführen <code>set <deviceName> getConfig</code>
# Ch01 (Sw) mit Ch05 (SenU) peeren <code>set <deviceName>_SenU peerChan 0 <deviceName>_Sw single set</code>
# Erneutes getConfig auf das Device durchführen <code>set <deviceName> getConfig</code>
# Register auf Ch01 (Sw) setzen <code> set <deviceName>_Sw regSet lgSwJtDlyOff on self01 </code> <code> set <deviceName>_Sw regSet lgSwJtOn on self01 </code> <code> set <deviceName>_Sw regSet shSwJtDlyOff on self01 </code> <code> set <deviceName>_Sw regSet shSwJtOn on self01 </code> <code> set <deviceName>_Sw regSet lgSwJtDlyOff on self05 </code> <code> set <deviceName>_Sw regSet lgSwJtOn on self05 </code> <code> set <deviceName>_Sw regSet shSwJtDlyOff on self05 </code> <code> set <deviceName>_Sw regSet shSwJtOn on self05 </code>
# Register auf Ch05 (SenU) setzen <code> set <deviceName>_SenU regSet cndTxRising on </code> <code> set <deviceName>_SenU regSet txThrHiVlt 200 </code> <code> set <deviceName>_SenU regSet txThrLoVlt 180 </code>

== Bekannte Probleme ==
* Sobald der PMSw1 selbst von der Spannungsversorgung getrennt worden ist, verliert er die bisherigen Verbrauchswerte.
* Nach einem Stromausfall steht der Schalter auf "Aus", das angeschlossene Gerät ist also ebenfalls aus. Dies kann - falls man den Aktor nur zur reinen Verbrauchsmessung verwendet - bei der Messung von z.B. Kühlschrank, Kühltruhe oder Heizung zu unerfreulichen Auswirkungen führen. Eine Abhilfe schaffen die unter [[#Tipps|Tipps]] aufgeführten Register-Einstellungen.
: Mit der Firmware 2.5 wurde am 16.3.2015 im Switch-Channel das Register powerUpAction eingeführt.

== Firmware Update ==
Empfohlene und erprobte Vorgehensweise beim [[HomeMatic Firmware Update|Update der Firmware]] wie {{Link2Forum|Topic=59000|Message=503989|LinkText=hier im Forum}} beschrieben. Besonders zu beachten:
* IO Device verwenden, das für Updates geeignet ist (Attribute IODev und IOgrp), ggf. andere IO Devices vorübergehend auf inaktiv setzen
* Aktor in Steckdose stecken und einschalten
* fwUpdate Kommando aus FHEM heraus absetzen
* Update kann zwei bis drei Minuten dauern (schnelles Blinken der LED (rot) am Aktor)
* ...

== Links ==
* [http://files.elv.de/Assets/Produkte/13/1302/130248/Downloads/130248_schaltaktor_messen_um.pdf Manual]
* [http://files.elv.de/Assets/Produkte/13/1302/130248/Downloads/130248_schaltaktor_messfunktion_data.pdf Datenblatt]
* [http://www.eq-3.de/produkte/homematic/licht/homematic-funk-schaltaktor-1-fach-mit-leistungsmessung-typ-f.html Produktinfo]
* [http://www.meintechblog.de/2014/01/homematic-funk-steckdose-mit-leistungsmessung-deine-waschmaschine-ist-fertig/ Beispiel-Anwendung]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Energieverbrauchsmessung]]
[[Kategorie:Schalter (Empfänger)]]

HomeMatic Peering Beispiele

2014-04-01T10:26:01Z

Mikezulugolf:

Dieser Artikel beschreibt wie mit FHEM Homematic Sensoren und Aktoren gepeert werden können. Peering ist nicht mit Pairing zu verwechseln - das wäre das Verknüpfen von Homematic Geräten mit einer Zentrale (wie beispielsweise FHEM über die IOs CUL oder HMLAN). Details zum Pairing findet man [[HomeMatic_Devices_pairen|'''hier''']].

= Grundlagen =
Peeren ist das Verknüpfen von Kanälen (Channels), um diese auch ohne Zentrale kommunizieren zu lassen. Mittels peering sendet ein Sensor-kanal (remote, push-button, Bewegungsmelder,...) trigger an einen Aktor-Kanal.
* peeren kann man nur Channels, nicht Devices
* gepeert wird immer ein Sensor mit einem Aktor
* Ein Sensor kann mit mehreren Aktor-kanälen gepeert sein
* Ein Aktor-channel kann mit mehreren Sensor-kanälen gepeert sein.
* der Sensor sendet eine Trigger, evtl mit einem Zusatz-wert. Es ist '''immer''' der Aktor-Kanal, der festlegt, welche Aktion ergriffen wird. Ein Button weiß also nicht, ob er ein Ein- oder Ausschalter ist, das weiss nur der Aktor! Ein Button kann demnach gleichzeitig ein Einschalter in einem Aktor und ein Ausschalter in einem anderen Aktor sein.

==Sensoren ==
Ist ein Sensor mit einem Aktor gepeert, gibt es meist nur wenig mögliche Einstellungen. Man kann meist einstellen, dass der Peer mit burst aufgeweckt werden muss (Register peerNeedsBurst). Auch ob man mit AES rechnen muss ist einstellbar (Register expectAES).
===LEDs===
Ein ungepeerter Sensor Kanal signalisiert einen Tastendruck meist mit gelber LED. Ist der Kanal gepeert wird mit einer grünen LED signalisiert, dass ALLE peers den Empfang des Triggers bestätigt (ACK gesendet) haben. Sollten nicht alle peers ein ACK senden wird mit rot quittiert.

==Aktoren==
Ist ein Sensor an den Aktor gepeert, muss im Aktor eingestellt werden, welche Trigger gültig sind und welche Aktionen ergriffen werden sollen. Im Channel wird ein Satz Register angelegt, die als Reading mit '''R-<peername>...''' zusammengefasst sind. Meist sind 2 Gruppen je peer vorhanden, eine für langen '''lg''' und eine für kurzen '''sh''' Tastendruck. Die Register für long und short sind deckungsgleich, bis auf das multiExec in der Gruppe long.
===Condition table===
Mit den Register der Condition Table '''CT''' kann man Trigger filtern. So sendet beispielsweise ein Fensterkontakt einen Trigger mit einem Zusatzwert open=200 oder closed=0. Die CT hat 2 Vergleichswerte, '''Hi''' und '''Lo'''. Der Zusatzwert des Triggers wird entsprechend des Einträgen in der CT-tabelle verglichen. Ist der Schalter z.B. an, dann wird auf den Eintrag in '''CTon''' genutzt. Steht dort '''geLo''' wird gprüft, ob der Zusatzwert des triggers grösser oder gleich dem Lo-Wert ist. Ist dies nicht der Fall, wird keine Aktion ausgeführt.
Register zur Conditiontable sind:
CtDlyOff | literal | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
CtDlyOn | literal | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
CtOff | literal | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
CtOn | literal | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
CtValHi |0 to 255 | Condition value high for CT table
CtValLo |0 to 255 | Condition value low for CT table
Remotes liefern keinen Zusatzwert. Die Conditontable wird nicht genutzt.
===jump table===
In der Jumptable wird festgelegt, zusammen mit ActionType, welche Aktion ein gültiger Trigger ausführen soll. Die Aktion ist vom Gerät abhängig

===internal peers===
Aktoren können eingebaute oder direkt angeschlossene Taster oder Taster-eingänge haben. Faktisch sind diese auch peers. Per Default sind diese nicht sichtbar. Man muss den Befehl
set <device> regSet intKeysVisib visib
eingeben, um diese sichtbar und einstellbar zu machen.

= Beispiele=
== Allgemein ==
Man kann Kanäle ohne Zentrale miteinander peeren. Das funktioniert nur, wenn keines der Devices gepairt ist. Dieser Fall wird hier nicht betrachtet.
Hier wird nur die Möglichkeit des peerens von Geräten betrachtet, die bereits mit einer Homematic-Zentrale (wie FHEM) [[HomeMatic_Devices_pairen|'''gepairt''']] sind. Die Grundsyntax des Befehls lautet:
:<code>set <sensChan> peerChan 0 <actChan></code>
wobei "<sensChan>" den Name des Sensor-Kanals (z.B.Button) und "<actChan>" den Name des Aktor-Kanals wiederspiegelt.
=== Ausführung ===
Es ist zu beachten, dass durch das Kommando die entsprechenden Nachrichten zur Verarbeitung in den Stack geschrieben werden. Je nach Gerät ist sicher zustellen, dass die Kommandos auch abgearbeitet werden. Je nach Gerät könnte es notwendig sein, Anlernen/Konfig zu drücken.
=== Auswirkung===
Das Peeren sollte immer in beiden Devices ausgeführt werden, dem Sensor und dem Aktor. Per Default ist das bei peerChan auch so.
== Peering der Kanäle einer Fernbedienung mit Jalousieaktoren ==
Beschrieben wird hier das Peering-Vorgehen einer HM-Fernbedienung mit 19 Tasten ([[HM-RC-19|HM-RC-19]]) mit mehreren HM Jalousieaktoren ([[HM-LC-Bl1-SM_Funk-Jalousieaktor|HM-LC-Bl1-SM]]).

set fb_Btn03 peerChan 0 blind
peert die Kanäle 03 und 04 mit dem Rollo. Dabei wird ein Button für hoch und einer für runter festgelegt.
set fb_Btn07 peerChan 0 blind single
peert nur den Button 07. Hier wird per Default ein toggle realisiert.

set fb_Btn07 peerChan 0 blind single unset
löscht den Peer wieder.

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]
[[Kategorie:Examples]]

HomeMatic Peering Beispiele

2014-04-01T10:21:06Z

Mikezulugolf:

Dieser Artikel beschreibt wie mit FHEM Homematic Sensoren und Aktoren gepeert werden können. Peering ist nicht mit Pairing zu verwechseln - das wäre das Verknüpfen von Homematic Geräten mit einer Zentrale (wie beispielsweise FHEM über die IOs CUL oder HMLAN). Details zum Pairing findet man [[HomeMatic_Devices_pairen|'''hier''']].

= Grundlagen =
Peeren ist das Verknüpfen von Kanälen um diese auch ohne Zentrale kommunizieren zu lassen. Mittels peering sendet ein Sensor-kanal (remote, push-button, Bewegungsmelder,...) trigger an einen Aktor-Kanal.
* peeren kann man nur Channels, nicht Devices
* gepeert wird immer ein Sensor mit einem Aktor
* Ein Sensor kann mit mehreren Aktor-kanälen gepeert sein
* Ein Aktor-channel kann mit mehreren Sensor-kanälen gepeert sein.
* der Sensor sendet eine Trigger, evtl mit einem Zusatz-wert. Es ist '''immer''' der Aktor-Kanal, der festlegt, welche Aktion ergriffen wird. Ein Button weiß also nicht, ob er ein Ein- oder Ausschalter ist, das weiss nur der Aktor! Ein Button kann demnach gleichzeitig ein Einschalter in einem Aktor und ein Ausschalter in einem anderen Aktor sein.

==Sensoren ==
Ist ein Sensor mit einem Aktor gepeert gibt es meist nur wenig mögliche Einstellungen. Man kann meist einstellen, dass der Peer mit burst aufgeweckt werden muss (Register peerNeedsBurst). Auch ob man mit AES rechnen muss ist einstellbar (Register expectAES).
===LEDs===
Ein ungepeerter Sensor Kanal signalisiert einen Tastendruck meist mit gelber LED. Ist der Kanal gepeert wird mit einer grünen LED signalisiert, dass ALLE peers den Empfang des Triggers bestätigt (ACK gesendet) haben. Sollten nicht alle peers ein ACK senden wird mit rot quittiert.

==Aktoren==
Ist ein Sensor an den Aktor gepeert muss im Aktor eingestellt werden, welche Trigger gültig sind und welche Aktionen ergriffen werden sollen. Im Channel wird ein Satz Register angelegt, die als Reading mit '''R-<peername>...''' zusammengefasst sind. Meist sind 2 Gruppen je peer vorhanden, eine für langen '''lg''' und eine für kurzen '''sh''' Tastendruck. Die Register für long und short sind deckungsgleich, bis auf das multiExec in der Gruppe long.
===Condition table===
Mit den Register der Condition Table '''CT''' kann man Trigger filtern. so sendet beispielsweise ein Fensterkontant einen Trigger mit einem Zusatzwert open=200 oder closed=0. Die CT hat 2 Vergleichswerte, '''Hi''' und '''Lo'''. Der Zusatzwert des Triggers wird entsprechend des Einträgen in der CT-tabelle verglichen. Ist der Schalter z.B. an, dann wird auf den Eintrag in '''CTon''' genutzt. Steht dort '''geLo''' wird gprüft, ob der Zusatzwert des triggers grösser ode rgleich dem Lo-Wert ist. Ist dies nicht der Fall wird keine Aktion ausgeführt.
Register zur Conditiontable sind:
CtDlyOff | literal | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
CtDlyOn | literal | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
CtOff | literal | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
CtOn | literal | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
CtValHi |0 to 255 | Condition value high for CT table
CtValLo |0 to 255 | Condition value low for CT table
Remotes liefern keinen zZusatzwert. Die Conditontable wird als nicht genutzt.
===jump table===
In der Jumptable wird festgelegt, zusammen mit ActionType, welche Aktion ein gültiger Trigger ausführen soll. Die Aktion ist vom Gerät abhängig

===internal peers===
Aktoren können eingebaute oder direkt angeschlossene Taster oder Taster-eingänge haben. Faktisch sind diese auch peers. Per Default sind diese nicht sichtbar. Man muss den Befehl
set <device> regSet intKeysVisib visib
eingeben, um diese sichtbar und einstellbar zu machen.

= Beispiele=
== Allgemein ==
Man kann Kanäle ohne Zentrale miteinander peeren. Das funktioniert nur, wenn keines der Devices gepairt ist. Dieser Fall wird hier nicht betrachtet.
Hier wird nur die Möglichkeit des peerens von Geräten betrachtet, die bereits mit einer Homematic-Zentrale (wie FHEM) [[HomeMatic_Devices_pairen|'''gepairt''']] sind. Die Grundsyntax des Befehls lautet:
:<code>set <sensChan> peerChan 0 <actChan></code>
wobei "<sensChan>" den Name des Sensor-Kanals (z.B.Button) und "<actChan>" den Name des Aktor-Kanals wiederspiegelt.
=== Ausführung ===
Es ist zu beachten, dass durch das Kommando die entsprechenden Nachrichten zur Verarbeitung in den Stack geschrieben werden. Je nach Gerät ist sicher zustellen, dass die Kommandos auch abgearbeitet werden. Je nach Gerät könnte es notwendig sein, Anlernen/Konfig zu drücken.
=== Auswirkung===
Das Peeren sollte immer in beiden Devices ausgeführt werden, dem Sensor und dem Aktor. Per Default ist das bei peerChan auch so.
== Peering der Kanäle einer Fernbedienung mit Jalousieaktoren ==
Beschrieben wird hier das Peering-Vorgehen einer HM-Fernbedienung mit 19 Tasten ([[HM-RC-19|HM-RC-19]]) mit mehreren HM Jalousieaktoren ([[HM-LC-Bl1-SM_Funk-Jalousieaktor|HM-LC-Bl1-SM]]).

set fb_Btn03 peerChan 0 blind
peert die Kanäle 03 und 04 mit dem Rollo. Dabei wird ein Button für hoch und einer für runter festgelegt.
set fb_Btn07 peerChan 0 blind single
peert nur den Button 07. Hier wird per Default ein toggle realisiert.

set fb_Btn07 peerChan 0 blind single unset
löscht den Peer wieder.

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]
[[Kategorie:Examples]]

HomeMatic Peering Beispiele

2014-04-01T10:07:15Z

Mikezulugolf:

Dieser Artikel beschreibt wie mit FHEM Homematic Sensoren und Aktoren gepeert werden können. Peering ist nicht mit Pairing zu verwechseln - das wäre das Verknüpfen von Homematic Geräten mit einer Zentrale (wie beispielsweise FHEM über die IOs CUL oder HMLAN). Details zum Pairing findet man [[HomeMatic_Devices_pairen|'''hier''']].

= Grundlagen =
Peeren ist das Verknüpfen von Kanälen um diese auch ohne Zentrale kommunizieren zu lassen. Mittels peering sendet ein Sensor-kanal (remote, push-button, Bewegungsmelder,...) trigger an einen Aktor-Kanal.
* peeren kann man nur Channels, nicht Devices
* gepeert wird immer ein Sensor mit einem Aktor
* Ein Sensor kann mit mehreren Aktor-kanälen gepeert sein
* Ein Aktor-channel kann mit mehreren Sensor-kanälen gepeert sein.
* der Sensor sendet eine Trigger, evtl mit einem Zusatz-wert. Es ist '''immer''' der Aktor-Kanal, der festlegt, welche Aktion ergriffen wird. Ein Button weiß also nicht, ob er ein Ein- oder Ausschalter ist, das weiss nur der Aktor! Ein Button kann demnach gleichzeitig ein Einschalter in einem Aktor und ein Ausschalter in einem anderen Aktor sein.

==Sensoren ==
Ist ein Sensor mit einem Aktor gepeert gibt es meist nur wenig mögliche Einstellungen. Man kann meist einstellen, dass der Peer mit burst aufgeweckt werden muss (Register peerNeedsBurst). Auch ob man mit AES rechnen muss ist einstellbar (Register expectAES).
===LEDs===
Ein ungepeerter Sensor Kanal signalisiert einen Tastendruck meist mit gelber LED. Ist der Kanal gepeert wird mit einer grünen LED signalisiert, dass ALLE peers den Empfang des Triggers bestätigt (ACK gesendet) haben. Sollten nicht alle peers ein ACK senden wird mit rot quittiert.

==Aktoren==
Ist ein Sensor an den Aktor gepeert muss im Aktor eingestellt werden, welche Trigger gültig sind und welche Aktionen ergriffen werden sollen. Im Channel wird ein Satz Register angelegt, die als Reading mit '''R-<peername>...''' zusammengefasst sind. Meist sind 2 Gruppen je peer vorhanden, eine für langen '''lg''' und eine für kurzen '''sh''' Tastendruck. Die Register für long und short sind deckungsgleich, bis auf das multiExec in der Gruppe long.
===Condition table===
Mit den Register der Condition Table '''CT''' kann man Trigger filtern. so sendet beispielsweise ein Fensterkontant einen Trigger mit einem Zusatzwert open=200 oder closed=0. Die CT hat 2 Vergleichswerte, '''Hi''' und '''Lo'''. Der Zusatzwert des Triggers wird entsprechend des Einträgen in der CT-tabelle verglichen. Ist der Schalter z.B. an, dann wird auf den Eintrag in '''CTon''' genutzt. Steht dort '''geLo''' wird gprüft, ob der Zusatzwert des triggers grösser ode rgleich dem Lo-Wert ist. Ist dies nicht der Fall wird keine Aktion ausgeführt.
Register zur Conditiontable sind:
CtDlyOff | literal | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
CtDlyOn | literal | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
CtOff | literal | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
CtOn | literal | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
CtValHi |0 to 255 | Condition value high for CT table
CtValLo |0 to 255 | Condition value low for CT table
Remotes liefern keinen zZusatzwert. Die Conditontable wird als nicht genutzt.
===jump table===
In der Jumptable wird festgelegt, zusammen mit ActionType, welche Aktion ein gültiger Trigger ausführen soll. Die Aktion ist vom Gerät abhängig

===internal peers===
Aktoren können eingebaute oder direkt angeschlossene Taster oder Taster-eingänge haben. Faktisch sind diese auch peers. Per Default sind diese nicht sichtbar. Man muss den Befehl
set <device> regSet intKeysVisib visib
eingeben, um diese sichtbar und einstellbar zu machen.

= Beispiele=
== Allgemein ==
Man kann Kanäle ohne Zentrale miteinander peeren. Das funktioniert nur, wenn keines der Devices gepairt ist. Dieser Fall wird hier nicht betrachtet.
Hier wird nur die Möglichkeit der peerens von Geräten betrachtet, die bereits mit einer Homematic-Zentrale (wie FHEM) [[HomeMatic_Devices_pairen|'''gepairt''']] sind. Die Grundsyntax des Befehls lautet:
:<code>set <sensChan> peerChan 0 <actChan></code>
wobei "<sensChan>" den Name des Sensor-Kanals (z.B.Button) und "<actChan>" den Name des Aktor-Kanals wiederspiegelt.
=== Ausführung ===
Es ist zu beachten, dass durch das Kommando die entsprechenden Nachrichten zur Verarbeitung in den Stack geschrieben werden. Je nach Gerät ist sicher zustellen, dass die Kommandos auch abgearbeitet werden. Je nach Gerät könnte es notwendig sein, Anlernen/Konfig zu drücken.
=== Auswirkung===
Das Peeren sollte immer in beiden Devices ausgeführt werden, dem Sensor und dem Aktor. Per Default ist das bei peerChan auch so.
== Peering der Kanäle einer Fernbedienung mit Jalousieaktoren ==
Beschrieben wird hier das Peering-Vorgehen einer HM-Fernbedienung mit 19 Tasten ([[HM-RC-19|HM-RC-19]]) mit mehreren HM Jalousieaktoren ([[HM-LC-Bl1-SM_Funk-Jalousieaktor|HM-LC-Bl1-SM]]).

set fb_Btn03 peerChan 0 blind
peert die Kanäle 03 und 04 mit dem Rollo. Dabei wird ein Button für hoch und einer für runter festgelegt.
set fb_Btn07 peerChan 0 blind single
peert nur den Button 07. Hier wird per Default ein toggle realisiert.

set fb_Btn07 peerChan 0 blind single unset
löscht den Peer wieder.

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]
[[Kategorie:Examples]]

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-04-01T09:39:16Z

Mikezulugolf:

{{Infobox Hardware
|Bild=Hm-lc-bl1-sm-angeschlossen-800.jpg
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 1-fach (Aufputz)
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,4W
|HWPoweredBy=Netz
|HWSize=160x115x55mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}
'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

== Features ==

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

== Hinweise zur Hardware-Installation ==

Dieser Jalousie-Aktor ist aus FHEM-Sicht analog zum [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Funk-Jalousieaktor]] zu konfigurieren. Aus physischer Sicht ist es ein größerer wetterfester Kasten, der zur Aufputz Montage im Außenbereich geeignet ist.

[[Bild:Hm-lc-bl1-sm-kabel-vorbereitet.jpg|thumb|left|HM-LC-Bl1-SM vor dem Anklemmen]]
Der Aktor kann an die Wand geschraubt oder auch einfach mit Montagekleber angeklebt werden.
Nach dem Abschrauben der äußeren und inneren Abdeckung sieht man das Innenleben.

Das rechte Kabel kommt mit seinen 4 Adern vom Hirschmannstecker der Jalousie, das linke Kabel kommt von der nächstgelegenen Verteilerdose.

{{Randnotiz|RNTyp=Fehl|RNText=Elektrische Arbeiten wie hier beschrieben überlässt man geschulten Fachkräften}}
[[Bild:Hm-lc-bl1-sm-kabel-angeklemmt.jpg|thumb|left|HM-LC-Bl1-SM nach dem Anklemmen]]
Deutlich zu erkennen sind die Klemmenblöcke. Am linken Block (KL2) werden die Adern des linken Kabels angeschlossen als auch vom rechten Kabel die PE-Ader (gelb-grün) und die Ader Nummer 1 (Nummer 1 vom Hirschmannstecker, N-Leiter). Von KL2-Phase ("L") wird eine Brücke zum rechten Block (KL1) zur L-Klemme (Mitte) gelegt. Abschließend wird die Ader 2 vom Hirschmannstecker an der rechten Klemme von KL1 ("1") und die Ader 3 vom Hirschmannstecker an der linken Klemme von KL1 ("2") verklemmt.

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-31T10:24:36Z

Mikezulugolf:

{{Infobox Hardware
|Bild=Hm-lc-bl1-sm-angeschlossen-800.jpg
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 1-fach (Aufputz)
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,4W
|HWPoweredBy=Netz
|HWSize=160x115x55mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}
'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

== Features ==

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

== Hinweise zur Hardware-Installation ==

Dieser Jalousie-Aktor ist aus FHEM-Sicht analog zum [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Funk-Jalousieaktor]] zu konfigurieren. Aus physischer Sicht ist es ein größerer wetterfester Kasten, der zur Aufputz Montage im Außenbereich geeignet ist.

Der Aktor kann an die Wand geschraubt oder auch einfach mit Montagekleber angeklebt werden.
Nach dem Abschrauben der äußeren und inneren Abdeckung sieht man das Innenleben.
[[Bild:Hm-lc-bl1-sm-kabel-vorbereitet.jpg|thumb|center|HM-LC-Bl1-SM vor dem Anklemmen]]
Das rechte Kabel kommt mit seinen 4 Adern vom Hirschmannstecker der Jalousie, das linke Kabel kommt von der nächstgelegenen Verteilerdose.

{{Randnotiz|RNTyp=Fehl|RNText=Elektrische Arbeiten wie hier beschrieben überlässt man geschulten Fachkräften}}
Deutlich zu erkennen sind die Klemmenblöcke. Am linken Block (KL2) werden die Adern des linken Kabels angeschlossen als auch vom rechten Kabel die PE-Ader (gelb-grün) und die Ader Nummer 1 (Nummer 1 vom Hirschmannstecker, N-Leiter). Von KL2-Phase ("L") wird eine Brücke zum rechten Block (KL1) zur L-Klemme (Mitte) gelegt. Abschließend wird die Ader 2 vom Hirschmannstecker an der rechten Klemme von KL1 ("1") und die Ader 3 vom Hirschmannstecker an der linken Klemme von KL1 ("2") verklemmt.
[[Bild:Hm-lc-bl1-sm-kabel-angeklemmt.jpg|thumb|center|HM-LC-Bl1-SM nach dem Anklemmen]]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-31T10:24:13Z

Mikezulugolf:

{{Infobox Hardware
|Bild=Hm-lc-bl1-sm-angeschlossen-800.jpg
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 1-fach (Aufputz)
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,4W
|HWPoweredBy=Netz
|HWSize=160x115x55mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

== Features ==

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

== Hinweise zur Hardware-Installation ==

Dieser Jalousie-Aktor ist aus FHEM-Sicht analog zum [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Funk-Jalousieaktor]] zu konfigurieren. Aus physischer Sicht ist es ein größerer wetterfester Kasten, der zur Aufputz Montage im Außenbereich geeignet ist.

Der Aktor kann an die Wand geschraubt oder auch einfach mit Montagekleber angeklebt werden.
Nach dem Abschrauben der äußeren und inneren Abdeckung sieht man das Innenleben.
[[Bild:Hm-lc-bl1-sm-kabel-vorbereitet.jpg|thumb|center|HM-LC-Bl1-SM vor dem Anklemmen]]
Das rechte Kabel kommt mit seinen 4 Adern vom Hirschmannstecker der Jalousie, das linke Kabel kommt von der nächstgelegenen Verteilerdose.

{{Randnotiz|RNTyp=Fehl|RNText=Elektrische Arbeiten wie hier beschrieben überlässt man geschulten Fachkräften}}
Deutlich zu erkennen sind die Klemmenblöcke. Am linken Block (KL2) werden die Adern des linken Kabels angeschlossen als auch vom rechten Kabel die PE-Ader (gelb-grün) und die Ader Nummer 1 (Nummer 1 vom Hirschmannstecker, N-Leiter). Von KL2-Phase ("L") wird eine Brücke zum rechten Block (KL1) zur L-Klemme (Mitte) gelegt. Abschließend wird die Ader 2 vom Hirschmannstecker an der rechten Klemme von KL1 ("1") und die Ader 3 vom Hirschmannstecker an der linken Klemme von KL1 ("2") verklemmt.
[[Bild:Hm-lc-bl1-sm-kabel-angeklemmt.jpg|thumb|center|HM-LC-Bl1-SM nach dem Anklemmen]]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-31T09:05:30Z

Mikezulugolf:

{{Infobox Hardware
|Bild=Hm-lc-bl1-sm-angeschlossen-800.jpg
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 1-fach (Aufputz)
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,4W
|HWPoweredBy=Netz
|HWSize=160x115x55mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

== Features ==

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

== Hinweise zur Hardware-Installation ==

Dieser Jalousie-Aktor ist aus FHEM-Sicht analog zum [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Funk-Jalousieaktor]] zu konfigurieren. Aus physischer Sicht ist es ein größerer wetterfester Kasten, der zur Aufputz Montage im Außenbereich geeignet ist.

Der Aktor kann an die Wand geschraubt oder auch einfach mit Montagekleber angeklebt werden.
Nach dem Abschrauben der äußeren und inneren Abdeckung sieht man das Innenleben.
[[Bild:Hm-lc-bl1-sm-kabel-vorbereitet.jpg|thumb|center|HM-LC-Bl1-SM vor dem Anklemmen]]
Das rechte Kabel kommt mit seinen 4 Adern vom Hirschmannstecker der Jalousie, das linke Kabel kommt von der nächstgelegenen Verteilerdose.

Deutlich zu erkennen sind die Klemmenblöcke. Am linken Block (KL2) werden die Adern des linken Kabels angeschlossen als auch vom rechten Kabel die PE-Ader (gelb-grün) und die Ader Nummer 1 (Nummer 1 vom Hirschmannstecker, N-Leiter). Von KL2-Phase ("L") wird eine Brücke zum rechten Block (KL1) zur L-Klemme (Mitte) gelegt. Abschließend wird die Ader 2 vom Hirschmannstecker an der rechten Klemme von KL1 ("1") und die Ader 3 vom Hirschmannstecker an der linken Klemme von KL1 ("2") verklemmt.
[[Bild:Hm-lc-bl1-sm-kabel-angeklemmt.jpg|thumb|center|HM-LC-Bl1-SM nach dem Anklemmen]]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

Datei:Hm-lc-bl1-sm-kabel-angeklemmt.jpg

2014-03-31T08:43:14Z

Mikezulugolf:

Datei:Hm-lc-bl1-sm-kabel-vorbereitet.jpg

2014-03-31T08:42:39Z

Mikezulugolf:

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-31T08:40:11Z

Mikezulugolf:

Datei:Hm-lc-bl1-sm-angeschlossen-800.jpg

2014-03-31T08:39:35Z

Mikezulugolf:

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-31T08:37:25Z

Mikezulugolf:

{{Infobox Hardware
|Bild=Hm-lc-bl1-sm-vor-der-installation-800.jpg
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 1-fach (Aufputz)
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,4W
|HWPoweredBy=Netz
|HWSize=160x115x55mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

{{Baustelle}}

== Features ==

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

== Hinweise zur Hardware-Installation ==

Dieser Jalousie-Aktor ist aus FHEM-Sicht analog zum [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Funk-Jalousieaktor]] zu konfigurieren. Aus physischer Sicht ist es ein größerer wetterfester Kasten, der zur Aufputz Montage im Außenbereich geeignet ist.

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

HomeMatic Peering Beispiele

2014-03-26T09:37:56Z

Mikezulugolf:

{{Baustelle}}
Dieser Artikel beschreibt Beispiele, wie mit FHEM Homematic Sensoren und Aktoren gepeert werden können. Peering ist nicht mit Pairing zu verwechseln - das wäre das Verknüpfen von Homematic Geräten mit einer Zentrale (wie beispielsweise FHEM mit CUL oder mit HMLAN). Details zum Pairing findet man z.B. [[HomeMatic_Devices_pairen|hier]].

== Peering der Kanäle einer Fernbedienung mit Jalousieaktoren ==
Beschrieben wird hier das Peering-Vorgehen einer HM-Fernbedienung mit 19 Tasten ([[HM-RC-19|HM-RC-19]]) mit mehreren HM Jalousieaktoren ([[HM-LC-Bl1-SM_Funk-Jalousieaktor|HM-LC-Bl1-SM]]).

Zunächst müssen die Aktoren und die Fernbedienung mit FHEM gepaired werden. Details sind unter [[HomeMatic_Devices_pairen|HomeMatic Devices pairen]] zu finden, daher ist dieser Schritt hier nur kurz angerissen.

Für jedes Gerät im FHEM das Kommando "set HMLAN hmPairForSec 600" eingeben - das gibt einem 10 Minuten Zeit um den zu pairenden HM-LC-Bl1-SM Aktor aufzusuchen und dort (falls man es vorher vergessen hat) auch noch den Deckel abzuschrauben und eine der beiden Taster für mehrere Sekunden (bis die LED blinkt) zu drücken.

Die Fernbedienung paired man ebenfalls mit "set HMLAN hmPairForSec nn" - hier reichen vielleicht auch nur 30 Sekunden, sofern man die Fernbedienung schon in der Hand hat - und einem kurzen Druck z.B. mit einem Zahnstocher auf die Pairing-Taste, die auf der Rückseite der Fernbedienung über eine kleine Öffnung oberhalb des Batteriefachs erreichbar ist. Die Fernbedienung blinkt eine Weile und zeigt während des Vorgangs "CONFIG" an.

Nach diesen Aktionen sind die gepairten Geräte im FHEM zu finden.

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]
[[Kategorie:Examples]]

HomeMatic Peering Beispiele

2014-03-26T09:37:19Z

Mikezulugolf:

{{Baustelle}}
Dieser Artikel beschreibt Beispiele, wie mit FHEM Homematic Sensoren und Aktoren gepeert werden können. Peering ist nicht mit Pairing zu verwechseln - das wäre das Verknüpfen von Homematic Geräten mit einer Zentrale (wie beispielsweise FHEM mit CUL oder mit HMLAN). Details zum Pairing findet man z.B. [[HomeMatic_Devices_pairen|hier]].

== Peering der Kanäle einer Fernbedienung mit Jalousieaktoren ==
Beschrieben wird hier das Peering-Vorgehen einer HM-Fernbedienung mit 19 Tasten ([[HM-RC-19|HM-RC-19]]) mit mehreren HM Jalousieaktoren ([[HM-LC-Bl1-SM_Funk-Jalousieaktor|HM-LC-Bl1-SM]]).

Zunächst müssen die Aktoren und die Fernbedienung mit FHEM gepaired werden. Details sind unter [[HomeMatic_Devices_pairen|HomeMatic Devices pairen]] zu finden, daher ist dieser Schritt hier nur kurz angerissen.
Für jedes Gerät im FHEM das Kommando "set HMLAN hmPairForSec 600" eingeben - das gibt einem 10 Minuten Zeit um den zu pairenden HM-LC-Bl1-SM Aktor aufzusuchen und dort (falls man es vorher vergessen hat) auch noch den Deckel abzuschrauben und eine der beiden Taster für mehrere Sekunden (bis die LED blinkt) zu drücken.
Die Fernbedienung paired man ebenfalls mit "set HMLAN hmPairForSec nn" - hier reichen vielleicht auch nur 30 Sekunden, sofern man die Fernbedienung schon in der Hand hat - und einem kurzen Druck z.B. mit einem Zahnstocher auf die Pairing-Taste, die auf der Rückseite der Fernbedienung über eine kleine Öffnung oberhalb des Batteriefachs erreichbar ist. Die Fernbedienung blinkt eine Weile und zeigt während des Vorgangs "CONFIG" an.
Nach diesen Aktionen sind die gepairten Geräte im FHEM zu finden.

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]
[[Kategorie:Examples]]

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-26T09:12:32Z

Mikezulugolf:

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 1-fach (Aufputz)
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,4W
|HWPoweredBy=Netz
|HWSize=160x115x55mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

{{Baustelle}}

== Features ==

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

== Hinweise zur Hardware-Installation ==

Dieser Jalousie-Aktor ist aus FHEM-Sicht analog zum [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Funk-Jalousieaktor]] zu konfigurieren. Aus physischer Sicht ist es ein größerer wetterfester Kasten, der zur Aufputz Montage im Außenbereich geeignet ist.

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

HomeMatic Peering Beispiele

2014-03-26T09:11:37Z

Mikezulugolf:

HomeMatic Peering Beispiele

2014-03-26T09:05:38Z

Mikezulugolf:

HomeMatic Peering Beispiele

2014-03-26T09:04:11Z

Mikezulugolf:

HomeMatic Peering Beispiele

2014-03-26T09:02:09Z

Mikezulugolf: Die Seite wurde neu angelegt: „{{Baustelle}} Dieser Artikel beschreibt Beispiele, wie mit FHEM Homematic Sensoren und Aktoren gepeert werden können. Peering ist nicht mit Pairing zu verwech…“

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-26T08:23:58Z

Mikezulugolf:

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 1-fach (Aufputz)
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,4W
|HWPoweredBy=Netz
|HWSize=160x115x55mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

{{Baustelle}}

= Features =

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

= Hinweise zur Hardware-Installation =

Dieser Jalousie-Aktor ist aus FHEM-Sicht analog zum [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Funk-Jalousieaktor]] zu konfigurieren. Aus physischer Sicht ist es ein größerer wetterfester Kasten, der zur Aufputz Montage im Außenbereich geeignet ist.

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-26T08:22:10Z

Mikezulugolf:

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 1-fach (Aufputz)
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,4W
|HWPoweredBy=Netz
|HWSize=160x115x55mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

{{Baustelle}}

= Features =

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

Dieser Jalousie-Aktor ist aus FHEM-Sicht analog zum [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Funk-Jalousieaktor]] zu konfigurieren. Aus physischer Sicht ist es ein größerer wetterfester Kasten, der zur Aufputz Montage im Außenbereich geeignet ist.

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-25T14:04:06Z

Mikezulugolf:

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 1-fach (Aufputz)
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,4W
|HWPoweredBy=Netz
|HWSize=160x115x55mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

{{Baustelle}}

= Features =

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-25T14:01:46Z

Mikezulugolf:

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 1-fach (Aufputz)
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,4W
|HWPoweredBy=Netz
|HWSize=160x115x55mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

(In Bearbeitung)

= Features =

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

HomeMatic Namen verstehen

2014-03-25T13:55:06Z

Mikezulugolf: /* Montageart */

HomeMatic Sender und Aktoren sind oft mit den Bezeichnungen des Herstellers (die ELV Tochtergesellschaft eQ-3) benannt.

Da es sich um Buchstaben und Zahlenkürzel handelt, ist nicht immer sofort erkennbar, um was für ein Gerät es sich handelt.

== Namensschema ==
Die Namen sind jedoch meist nach einem Schema aufgebaut, der Aufbau ist meist:

Medientyp - Generelle Funktion - Sensor/Sender/Aktorfunktion [mit Taster] - [Montageart]

also z.b. HM-LC-SW1-FM

Die Gross- und Kleinschreibung wird nicht durchgängig stringent eingehalten. So wird die Aktorfunktion Schalter mal mit SW, mal mit Sw bezeichnet.
[ ] umschliessen optionale Bestandteile

Ferner hält sich ELV nicht vollumfänglich an sein Namenschema.
Die LED Statusanzeige heisst z.b. HM-OU-LED16, müsste nach Namenschema aber eigentlich HM-Dis-16 heissen.

Es bedeuten (Liste unvollständig):

== Medientyp ==
* HM = HomeMatic Funk
* HMW = HomeMatic Wired
== Funktion ==
* CC = Heizungssteuerung (Climate Control)
* LC = Licht/Strom (Light Control)
* SEC = Überwachung (Security) (auch Sec)
* RC = Fernbedienung (Radio Control)
* Sen = Sensor
* WDSxx = Feuchte- und/oder Temperatursensor
* PB = Wandtaster (Push Button)
* PBI = Tasterschnittstelle (Push Button Interface)
* DIMxT = Dimmer mit x Kanälen mit Phasenschnittsteuerung (Thyristor Dimmer)
* DIMxL = Dimmer mit x Kanälen Leistungsdimmer für ohmsche/induktive Lasten
* OU = Klang
* Dis = Anzeige

== Sensor/Sender/Aktorfunktion ==
* SWx = Schaltaktor mit x Kanälen (Switch) (oft auch Swx)
* TiS = Neigungssensor (Tilt Sensor)
* Px = Paniksender mit x Kanälen (Panic)
* WDS = Wassermelder
* SC = Tür- / Fenster / Schliesserkontakt (Shutter Contact)
* EP = (Sensor für) Elektrische Impulse
* TH = Temperatur und Feuchtesensor (Temperature & Humidity)
* T = Temperatursensor
* MDIR = Infrarot Bewegungsmelder (Motion Detector Infrared)
* BLx = Jalousieaktor mit x Kanälen (Blind) (oft auch Blx)
* VD = Stellantrieb (Ventile Drive)
* SCD = Luftgütesensor (Sensor Carbon Dioxide)
* CF = Gong (Chime)
* 2 = Zweikanal
* 4 = Vierkanal
* 12 = Zwölfkanal
* 16 = Sechzehnkanal
* 19 = Neunzehnkanal

== Montageart ==
(optional angefügt nur soweit bedeutsam, z.b. um Geräte ansonsten gleicher Funktion zu unterscheiden)

* FM = Unterputz (Floating Mount)
* WM = beliebige Festmontage, meist Aufklebegerät (Wall Mount)
* SM = Aufputz (Surface Mount)
* CV = Zwischendeckenmontage (Ceiling mount)
* PL = Zwischenstecker (Plug) (oft auch Pl)
* DR = Hutschienenmontage (DIN Rail)
* O = Aussenmontage (Outdoor)
* I = Innenmontage (Indoor)
* T = Frei aufstellbares Gerät (eventuell von "Tabletop")

ausserdem:

* B = schwarz
* SW = weiss
* PCB = Bausatz / Platinenversion

== Beispiel ==
HM-LC-SW1-FM = HomeMatic Funk - Licht/Strom - Schaltaktor mit einem Kanal - Unterputzmontage

HM-LC-Sw2PB-FM = HomeMatic Funk - Licht/Strom - Schaltaktor mit zwei Kanälen UND Tastern - Unterputzmontage

[[Kategorie:HOWTOS]]

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-25T13:35:16Z

Mikezulugolf:

'''HM-LC-Bl1-SM''' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

(In Bearbeitung)

= Features =

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

HM-LC-Bl1-SM Funk-Jalousieaktor

2014-03-25T13:34:56Z

Mikezulugolf: Die Seite wurde neu angelegt: „'''HM-LC-Bl1-SM'' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz) (In Bearbeitung) = Features = Schalten eines angeschlossenen Jalousiemotors mittels …“

'''HM-LC-Bl1-SM'' ist ein Homematic Funk-Jalousieaktor 1-fach (Aufputz)

(In Bearbeitung)

= Features =

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über die eingebauten Taster.

'''Technische Daten:'''
* Schaltvermögen: max 800W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,4W
* Maße(BxHxT): 160x115x55mm

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

OWServer & OWDevice

2014-03-25T12:54:02Z

Mikezulugolf:

==Einleitung==

Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, welche die angeschlossenen Module definiert-
Die Module benötigen die Serverkomponente von [http://www.owfs.org OWFS].

'''Wichtig:'''

Die Module sind eine eigenständige Möglichkeit, den 1-Wire Bus anzusteuern und kommen ohne die Module aus, deren Namen aus Großbuchstaben bestehen (wie OWX, OWSWITCH, OWTHERM, etc.).
Umgekehrt können die Module OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die commandref der betreffenden Module.

==Vorbereitung==

Wie oben erwähnt, setzt OWServer/OWDevice auf OWFS auf. Dazu ist eine funktionierende OWFS Installation notwendig. Die Installation ist auf der selben Plattform (Debian-based) möglich oder auch Remote (zBsp Dockstar oder RPi). Eine gute [http://owfs.org/index.php?page=standard-devices Liste der Standard Devices]auf der Homepage von OWFS einzusehen. Nicht alle Standard Devices sind in OWDevice verfügbar (siehe unten).Wenn OWFS funktioniert kann's weiter gehen...

===owfs Pakete installieren===

1) entweder sind die Pakete bereits vorpaketiert und man muss nur das [http://owfs.davromaniak.eu/ Repository] noch in /etc/apt/sources.list eintragen

2) oder man muss selber kompilieren ([http://www.navitron.org.uk/forum/index.php?topic=12604.msg151750#msg151750 Quelle]).
Für den RaspberryPi wurde dies schon durchgeführt: [http://forum.fhem.de/index.php?action=dlattach;topic=12219.0;attach=2463 owfs_2.8p17-1_all.zip]

<nowiki>sudo apt-get install automake autoconf autotools-dev gcc g++ libtool libusb-dev fuse-utils libfuse-dev swig python-dev tcl-dev php5-dev
sudo apt-get install git git-buildpackage dh-make quilt php5-cli
git clone [git://git.debian.org/collab-maint/owfs.git git://git.debian.org/collab-maint/owfs.git] git
git-buildpackage -uc -us
cd ..
sudo dpkg -i ./owserver_2.8p7+cvs20110310-1_i386.deb ./libow-2.8-7_2.8p7+cvs20110310-1_i386.deb ./owfs-common_2.8p7+cvs20110310-1_all.deb
sudo dpkg -i ./owhttpd_2.8p7+cvs20110310-1_i386.deb</nowiki>
diese Pakete werden alle gebaut:

<nowiki>libow-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-common_2.8p7+cvs20110310-1_all.deb
libowcapi-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-dbg_2.8p7+cvs20110310-1_i386.deb
libow-dev_2.8p7+cvs20110310-1_i386.deb owfs-doc_2.8p7+cvs20110310-1_all.deb
libownet-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-fuse_2.8p7+cvs20110310-1_i386.deb
libownet-dev_2.8p7+cvs20110310-1_i386.deb owftpd_2.8p7+cvs20110310-1_i386.deb
libownet-perl_2.8p7+cvs20110310-1_all.deb owhttpd_2.8p7+cvs20110310-1_i386.deb
libownet-php_2.8p7+cvs20110310-1_all.deb owserver_2.8p7+cvs20110310-1_i386.deb
libow-perl_2.8p7+cvs20110310-1_i386.deb ow-shell_2.8p7+cvs20110310-1_i386.deb
libow-php5_2.8p7+cvs20110310-1_i386.deb python-ow_2.8p7+cvs20110310-1_i386.deb
libow-tcl_2.8p7+cvs20110310-1_i386.deb python-ownet_2.8p7+cvs20110310-1_all.deb
owfs_2.8p7+cvs20110310-1_all.deb</nowiki>

===Unterstütze Geräte===
Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im [http://fhem.de/commandref.html#OWDevice FHEM-Commandref].

==Konfiguration in FHEM==
Als erstes definiert man OWServer. Hiermit wird ein logischer OWServer definiert, auf welchem OWFS installiert ist

<nowiki>define <name> OWServer <protocol></nowiki>
<protocol> hat das Format <hostname>:<port>.

zBsp:

<nowiki>define myOWServer OWServer 192.168.14.100:4304</nowiki>
oder wenn sich OWFS auf dem gleichen Server befindet wie FHEM:

<nowiki>define myOWServer OWServer localhost:4304</nowiki>
Nach erfolgreichem "define" ist ein Klick auf den "Save" Button notwenig. Wenn nun der Status von myOWServer auf "Initialized" steht, ist der Server verbunden. Um sicher zu sein, dass der OWServer funktioniert, kann eine manuelle Abfrage der Device durchgeführt werden mit:

<nowiki>get myOWServer devices</nowiki>
Danach werden sämtliche angeschlossene Geräte angezeigt, inkl. Busmaster

===OWServer Set Befehle===
<nowiki>set <name> <value>
value:
timeout/directory
timeout/ftp
timeout/ha7
timeout/network
timeout/presence
timeout/serial
timeout/server
timeout/stable
timeout/uncached
timeout/usb
timeout/volatile
timeout/w1
units/pressure_scale
units/temperature_scale</nowiki>
Weitere Informationen zu den Set Befehlen sind im [http://owfs.org/uploads/owserver.1.html#sect41 OWServer Manual] zu entnehmen.

===OWServer Get Befehle===
<nowiki>get <name> <value>
value:
/settings/timeout/directory
/settings/timeout/ftp
/settings/timeout/ha7
/settings/timeout/network
/settings/timeout/presence
/settings/timeout/serial
/settings/timeout/server
/settings/timeout/stable
/settings/timeout/uncached
/settings/timeout/usb
/settings/timeout/volatile
/settings/timeout/w1
/settings/units/pressure_scale
/settings/units/temperature_scale</nowiki>
Zusätzlich stehen die FHEM-internen Befehle "errors" und "devices" zur Verfügung.
zBsp:

<nowiki>get <Devicename> errors #listet die Fehler des Device auf
get <Devicename> devices #scan den Server nach Device</nowiki>

===Angeschlossene Geräte auslesen===
Grundsätzlich werden die am Busmaster von OWFS angeschlossenen 1-Wire Geräte durch aktives autocreate nach einem Neustart (erfordert shutdown restart) selber in FHEM definiert.
Der Busmaster (zBsp ein DS9490r) selbst wird ebenfalls eingelesen und angezeigt.

===Definition von Geräten===
Es ist auch möglich, Geräte manuell anzulegen. Dies erfolgt in folgendem Format:

<nowiki>define <name> OWDevice <address> [<interval>]</nowiki>
zBsp:

<nowiki>define Vorlauftemp OWDevice 28.334F2B040000 60</nowiki>
Wobei der Wert 60 als Abfrageintervall in Sekunden zu verstehen ist.

===OWDevice State===
Bei Temperaturfühler wie DS18S20 wird das Reading "state" wie folgt ausgegeben:

<nowiki>temperature: 56.1875 alarm: 1</nowiki>
Um die Temperatur wie bei anderen Temperatur-Sensoren (zBsp. CUL_WS) anzuzeigen, hilft das Attribut "stateFormat". Dies kann wie folgt definiert werden:

<nowiki>attr <Devicename> stateFormat T: <wert></nowiki>
zBsp:

<nowiki>attr Boiler stateFormat T: temperature</nowiki>
alternativ

<nowiki>attr <Devicename> stateFormat {sprintf("%.1f",ReadingsVal("<Devicename>","temperature",0))."°C"}</nowiki>
Zusätzlich rundet das obenstehende Attribut mit "%.1f" die Temperatur auf eine Kommastelle.

==Tipps und Tricks==
1-wire-Geräte sind häufig generische Geräte, wie Zähler und Spannungsmesser (A/D-Wandler), an denen Sensorik hängt. Die rohen Werte vom 1-wire-Gerät (Zählimpulse, Spannungen) sind dann noch in menschenlesbare Werte zu verwandeln. Hier helfen userReadings, z.B.

<nowiki>attr myEnergyMeter userReadings energy { (ReadingsVal("myEnergyMeter","count.A",0)+AttrVal("myEnergyMeter","myBasis",0))/1250.0;; }</nowiki>

==Anwendungsbeispiele==
[[Stromzähler_und_1-Wire,_OWServer,_OWDevice|Hier]] findet man ein Beispiel einer Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

[[Kategorie:1-Wire]]

OWServer & OWDevice

2014-03-25T12:53:32Z

Mikezulugolf:

==Einleitung==

Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, welche die angeschlossenen Module definiert-
Die Module benötigen die Serverkomponente von [http://www.owfs.org OWFS].

'''Wichtig:'''

Die Module sind eine eigenständige Möglichkeit, den 1-Wire Bus anzusteuern und kommen ohne die Module aus, deren Namen aus Großbuchstaben bestehen (wie OWX, OWSWITCH, OWTHERM, etc.).
Umgekehrt können die Module OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die commandref der betreffenden Module.

==Vorbereitung==

Wie oben erwähnt, setzt OWServer/OWDevice auf OWFS auf. Dazu ist eine funktionierende OWFS Installation notwendig. Die Installation ist auf der selben Plattform (Debian-based) möglich oder auch Remote (zBsp Dockstar oder RPi). Eine gute [http://owfs.org/index.php?page=standard-devices Liste der Standard Devices]auf der Homepage von OWFS einzusehen. Nicht alle Standard Devices sind in OWDevice verfügbar (siehe unten).Wenn OWFS funktioniert kann's weiter gehen...

===owfs Pakete installieren===

1) entweder sind die Pakete bereits vorpaketiert und man muss nur das [http://owfs.davromaniak.eu/ Repository] noch in /etc/apt/sources.list eintragen

2) oder man muss selber kompilieren ([http://www.navitron.org.uk/forum/index.php?topic=12604.msg151750#msg151750 Quelle]).
Für den RaspberryPi wurde dies schon durchgeführt: [http://forum.fhem.de/index.php?action=dlattach;topic=12219.0;attach=2463 owfs_2.8p17-1_all.zip]

<nowiki>sudo apt-get install automake autoconf autotools-dev gcc g++ libtool libusb-dev fuse-utils libfuse-dev swig python-dev tcl-dev php5-dev
sudo apt-get install git git-buildpackage dh-make quilt php5-cli
git clone [git://git.debian.org/collab-maint/owfs.git git://git.debian.org/collab-maint/owfs.git] git
git-buildpackage -uc -us
cd ..
sudo dpkg -i ./owserver_2.8p7+cvs20110310-1_i386.deb ./libow-2.8-7_2.8p7+cvs20110310-1_i386.deb ./owfs-common_2.8p7+cvs20110310-1_all.deb
sudo dpkg -i ./owhttpd_2.8p7+cvs20110310-1_i386.deb</nowiki>
diese Pakete werden alle gebaut:

<nowiki>libow-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-common_2.8p7+cvs20110310-1_all.deb
libowcapi-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-dbg_2.8p7+cvs20110310-1_i386.deb
libow-dev_2.8p7+cvs20110310-1_i386.deb owfs-doc_2.8p7+cvs20110310-1_all.deb
libownet-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-fuse_2.8p7+cvs20110310-1_i386.deb
libownet-dev_2.8p7+cvs20110310-1_i386.deb owftpd_2.8p7+cvs20110310-1_i386.deb
libownet-perl_2.8p7+cvs20110310-1_all.deb owhttpd_2.8p7+cvs20110310-1_i386.deb
libownet-php_2.8p7+cvs20110310-1_all.deb owserver_2.8p7+cvs20110310-1_i386.deb
libow-perl_2.8p7+cvs20110310-1_i386.deb ow-shell_2.8p7+cvs20110310-1_i386.deb
libow-php5_2.8p7+cvs20110310-1_i386.deb python-ow_2.8p7+cvs20110310-1_i386.deb
libow-tcl_2.8p7+cvs20110310-1_i386.deb python-ownet_2.8p7+cvs20110310-1_all.deb
owfs_2.8p7+cvs20110310-1_all.deb</nowiki>

===Unterstütze Geräte===
Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im [http://fhem.de/commandref.html#OWDevice FHEM-Commandref].

==Konfiguration in FHEM==
Als erstes definiert man OWServer. Hiermit wird ein logischer OWServer definiert, auf welchem OWFS installiert ist

<nowiki>define <name> OWServer <protocol></nowiki>
<protocol> hat das Format <hostname>:<port>.

zBsp:

<nowiki>define myOWServer OWServer 192.168.14.100:4304</nowiki>
oder wenn sich OWFS auf dem gleichen Server befindet wie FHEM:

<nowiki>define myOWServer OWServer localhost:4304</nowiki>
Nach erfolgreichem "define" ist ein Klick auf den "Save" Button notwenig. Wenn nun der Status von myOWServer auf "Initialized" steht, ist der Server verbunden. Um sicher zu sein, dass der OWServer funktioniert, kann eine manuelle Abfrage der Device durchgeführt werden mit:

<nowiki>get myOWServer devices</nowiki>
Danach werden sämtliche angeschlossene Geräte angezeigt, inkl. Busmaster

===OWServer Set Befehle===
<nowiki>set <name> <value>
value:
timeout/directory
timeout/ftp
timeout/ha7
timeout/network
timeout/presence
timeout/serial
timeout/server
timeout/stable
timeout/uncached
timeout/usb
timeout/volatile
timeout/w1
units/pressure_scale
units/temperature_scale</nowiki>
Weitere Informationen zu den Set Befehlen sind im [http://owfs.org/uploads/owserver.1.html#sect41 OWServer Manual] zu entnehmen.

===OWServer Get Befehle===
<nowiki>get <name> <value>
value:
/settings/timeout/directory
/settings/timeout/ftp
/settings/timeout/ha7
/settings/timeout/network
/settings/timeout/presence
/settings/timeout/serial
/settings/timeout/server
/settings/timeout/stable
/settings/timeout/uncached
/settings/timeout/usb
/settings/timeout/volatile
/settings/timeout/w1
/settings/units/pressure_scale
/settings/units/temperature_scale</nowiki>
Zusätzlich stehen die FHEM-internen Befehle "errors" und "devices" zur Verfügung.
zBsp:

<nowiki>get <Devicename> errors #listet die Fehler des Device auf
get <Devicename> devices #scan den Server nach Device</nowiki>

===Angeschlossene Geräte auslesen===
Grundsätzlich werden die am Busmaster von OWFS angeschlossenen 1-Wire Geräte durch aktives autocreate nach einem Neustart (erfordert shutdown restart) selber in FHEM definiert.
Der Busmaster (zBsp ein DS9490r) selbst wird ebenfalls eingelesen und angezeigt.

===Definition von Geräten===
Es ist auch möglich, Geräte manuell anzulegen. Dies erfolgt in folgendem Format:

<nowiki>define <name> OWDevice <address> [<interval>]</nowiki>
zBsp:

<nowiki>define Vorlauftemp OWDevice 28.334F2B040000 60</nowiki>
Wobei der Wert 60 als Abfrageintervall in Sekunden zu verstehen ist.

===OWDevice State===
Bei Temperaturfühler wie DS18S20 wird das Reading "state" wie folgt ausgegeben:

<nowiki>temperature: 56.1875 alarm: 1</nowiki>
Um die Temperatur wie bei anderen Temperatur-Sensoren (zBsp. CUL_WS) anzuzeigen, hilft das Attribut "stateFormat". Dies kann wie folgt definiert werden:

<nowiki>attr <Devicename> stateFormat T: <wert></nowiki>
zBsp:

<nowiki>attr Boiler stateFormat T: temperature</nowiki>
alternativ

<nowiki>attr <Devicename> stateFormat {sprintf("%.1f",ReadingsVal("<Devicename>","temperature",0))."°C"}</nowiki>
Zusätzlich rundet das obenstehende Attribut mit "%.1f" die Temperatur auf eine Kommastelle.

==Tipps und Tricks==
1-wire-Geräte sind häufig generische Geräte, wie Zähler und Spannungsmesser (A/D-Wandler), an denen Sensorik hängt. Die rohen Werte vom 1-wire-Gerät (Zählimpulse, Spannungen) sind dann noch in menschenlesbare Werte zu verwandeln. Hier helfen userReadings, z.B.

<nowiki>attr myEnergyMeter userReadings energy { (ReadingsVal("myEnergyMeter","count.A",0)+AttrVal("myEnergyMeter","myBasis",0))/1250.0;; }</nowiki>

==Anwendungsbeispiele==
[[Stromzähler_und_1-Wire,_OWServer,_OWDevice|Hier]]) findet man ein Beispiel einer Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

[[Kategorie:1-Wire]]

Benutzer:Mikezulugolf

2014-03-18T12:01:45Z

Mikezulugolf: /* Über mich */

Stromzähler und 1-Wire, OWServer, OWDevice

2014-01-21T14:46:21Z

Mikezulugolf:

Dieser Artikel beschreibt eine Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

Das Ziel ist anstatt des monatlichen manuellen Ablesens des Einspeisezählers, eine granulare und automatisierte Aufzeichnung der Leistung einer Photovoltaikanlage zu erhalten.

[[Datei:fhemwiki-grafik-s0counter-und-onewire.gif]]

Zwischen die beiden Wechselrichter und dem Einspeisezähler sind je ein digitaler Stromzähler mit S0-Ausgang geschaltet.
Einer dieser Stromzähler liefert 2000 Impulse pro kWh, der andere 1000 Impulse pro kWh.

Diese beiden Stromzähler sind mit einem auf dem 1-Wire Baustein DS2423 basierenden Dual S0 Counter verbunden, der hier über einen
USB-Busmaster als serielles Interface mit einer Instanz eines OWServers verbunden ist.

In FHEM ist dieser OWServer wie folgt definiert:
<code>define myOWServer OWServer 192.168.1.12:4304</code>
Es wird hier ein OWServer definiert, der über die IP-Adresse 192.168.1.12 erreichbar ist und dort auf dem Port 4304 auf Anfragen lauscht.

Ist in FHEM das "autocreate" Flag gesetzt, dann findet FHEM den S0-Counter und erzeugt beispielsweise die folgenden Einträge:
<nowiki>define DS2423_58E50F000000 OWDevice 1D.58E50F000000 60
attr DS2423_58E50F000000 model DS2423
attr DS2423_58E50F000000 room OWDevice</nowiki>
Unter "DS2423_58E50F000000" kann man sich nicht direkt etwas vorstellen und anstatt alle 60 Sekunden ein Update zu holen, sollten auch 5 Minuten (=300 Sekunden) reichen. Daher wird das abgeändert zu:
<nowiki>define PVZaehler OWDevice 1D.58E50F000000 300
attr PVZaehler model DS2423
attr PVZaehler room OWDevice </nowiki>
Dann definiert man noch ein Logfile dazu:
<nowiki>define FileLog_PVZaehler FileLog ./log/PVZaehler-%Y.log PVZaehler:.*
attr FileLog_PVZaehler logtype text</nowiki>
und findet dort Einträge der Form
<nowiki>...
2014-01-20_16:09:55 PVZaehler counters.A: 282478
2014-01-20_16:09:55 PVZaehler counters.B: 139840
2014-01-20_16:14:58 PVZaehler counters.A: 282478
2014-01-20_16:14:58 PVZaehler counters.B: 139841
...</nowiki>
Wie man sieht, erscheinen für jeden der beiden Counter in diesem 1-Wire Device eine eigene Zeile mit dem aktuellen Wert des Zählers.
Da der erste S0-Zähler 2000 Impulse pro kWh liefert, ist der Wert für "counters.A" auch etwa das Doppelte von "counters.B", dessen
zugehöriger S0-Zähler ja nur 1000 Impulse pro kWh liefert.

Eigentlich wäre es wünschenswert,
nur eine Zeile mit beiden Werten zu loggen, diese mit der passenden Einheit Watt-Stunden (Wh) zu bezeichnen und auch noch die Summe der beiden Werte aufzuzeichnen.

Die "state" Zeile im Reading des Devices

[[Datei:owdevice-pvzaehler-reading.png]]

beinhaltet die Werte beider Counter, aber das "state" Reading verursacht laut [http://fhem.de/commandref.html#OWDevice CommandRef] keinen Event,
den man in einer FileLog Definition einfach verwenden könnte.

Es muss also etwas mehr getan werden. Die Idee ist, ein Dummy-Device zu definieren und dazu ein passendes Notify, das auf die "PVZaehler" Events reagiert und
den Wert an dieses Dummy-Device weitergibt, in dessen Filelog die Daten dann aufgezeichnet werden.

Im Einzelnen:
<code>define PVErtrag dummy </code>
definiert das Dummy-Device, das die Erträge der Anlage erhalten soll.

Mit
<nowiki>1: define notify_PVErtrag notify PVZaehler:counters\.A.* { \
2: my $a = ReadingsVal("PVZaehler","counters.A",0)/2 ;; \
3: my $b = ReadingsVal("PVZaehler","counters.B",0) ;; \
4: my $c = $a+$b ;; \
5: my $text = "WR1: $a Wh, WR2: $b Wh, Gesamt: $c Wh" ;; \
6: fhem ("set PVErtrag $text") ;; \
7: } </nowiki>
werden die Daten erzeugt und an das PVErtrag Device geschickt.

In Zeile 1 wird das Notify definiert: "PVZaehler" ist das Device, auf dessen Events
reagiert werden soll und "counters\.A.*" der reguläre Ausdruck, auf den das Notify reagieren soll. Der Punkt in "counters.A" ist mit einem Backslash maskiert,
da er sonst als Metazeichen für den regulären Ausdruck interpretiert werden würde. Das ".*" bezeichnet x-beliebigen Text.

Wenn nun also das PVZaehler-Device
einen Event verursacht, der die Zeichenkette "counters.A" enthält, dann wird der in geschweiften Klammern stehende Perl-Code ausgeführt.
Dabei dienen die Backslashes jeweils am Zeilenende als Hinweis für FHEM, dass der Perl-Code noch nicht zu Ende ist, sondern in der nächsten Zeile fortgeführt wird.
Ebenso sind entsprechend der [http://fhem.de/commandref.html#perl CommandRef] die Semikolons in der fhem.cfg verdoppelt.
Zeile 2 definiert eine Variable $a und weist ihr den Wert des "counters.A" geteilt durch 2 zu; in Zeile 3 erhält die Variable $b den Wert des "counters.B". In Zeile 4
werden die beiden Werte addiert und in Zeile 5 schliesslich zu einem Ausgabetext zusammengesetzt. Zeile 6 sendet dann diesen Ausgabetext an das PVErtrag Device.

Schliesslich wird mit
<nowiki>define FileLog_PVErtrag FileLog ./log/FileLog_PVErtrag-%Y-%m.log PVErtrag
attr FileLog_PVErtrag logtype text </nowiki>

das Filelog erzeugt, in dem die Daten abgelegt werden. Hier ein Auszug aus diesem FileLog:
<nowiki>...
2014-01-21_13:15:22 PVErtrag WR1: 141666 Wh, WR2: 140271 Wh, Gesamt: 281937 Wh
2014-01-21_13:20:22 PVErtrag WR1: 141677 Wh, WR2: 140282 Wh, Gesamt: 281959 Wh
2014-01-21_13:25:22 PVErtrag WR1: 141687.5 Wh, WR2: 140293 Wh, Gesamt: 281980.5 Wh
2014-01-21_13:30:22 PVErtrag WR1: 141697 Wh, WR2: 140302 Wh, Gesamt: 281999 Wh
2014-01-21_13:35:22 PVErtrag WR1: 141705.5 Wh, WR2: 140311 Wh, Gesamt: 282016.5 Wh
... </nowiki>

[[Kategorie:1-Wire]]
[[Kategorie:HOWTOS]]
[[Kategorie:Code Snippets]]
[[Kategorie:Stromverbrauchsmesser]]
[[Kategorie:Examples]]

Stromzähler und 1-Wire, OWServer, OWDevice

2014-01-21T14:05:48Z

Mikezulugolf:

Stromzähler und 1-Wire, OWServer, OWDevice

2014-01-21T14:02:11Z

Mikezulugolf:

Dieser Artikel beschreibt eine Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

Das Ziel ist anstatt des monatlichen manuellen Ablesens des Einspeisezählers, eine granulare und automatisierte Aufzeichnung der Leistung einer Photovoltaikanlage zu erhalten.

[[Datei:fhemwiki-grafik-s0counter-und-onewire.gif]]

Zwischen die beiden Wechselrichter und dem Einspeisezähler sind je ein digitaler Stromzähler mit S0-Ausgang geschaltet.
Einer dieser Stromzähler liefert 2000 Impulse pro kWh, der andere 1000 Impulse pro kWh.

Diese beiden Stromzähler sind mit einem auf dem 1-Wire Baustein DS2423 basierenden Dual S0 Counter verbunden, der hier über einen
USB-Busmaster als serielles Interface mit einer Instanz eines OWServers verbunden ist.

In FHEM ist dieser OWServer wie folgt definiert:
<code>define myOWServer OWServer 192.168.1.12:4304</code>
Es wird hier ein OWServer definiert, der über die IP-Adresse 192.168.1.12 erreichbar ist und dort auf dem Port 4304 auf Anfragen lauscht.

Ist in FHEM das "autocreate" Flag gesetzt, dann findet FHEM den S0-Counter und erzeugt beispielsweise die folgenden Einträge:
<nowiki>define DS2423_58E50F000000 OWDevice 1D.58E50F000000 60
attr DS2423_58E50F000000 model DS2423
attr DS2423_58E50F000000 room OWDevice</nowiki>
Unter "DS2423_58E50F000000" kann man sich nicht direkt etwas vorstellen und anstatt alle 60 Sekunden ein Update zu holen, sollten auch 5 Minuten (=300 Sekunden) reichen. Daher wird das abgeändert zu:
<nowiki>define PVZaehler OWDevice 1D.58E50F000000 300
attr PVZaehler model DS2423
attr PVZaehler room OWDevice </nowiki>
Dann definiert man noch ein Logfile dazu:
<nowiki>define FileLog_PVZaehler FileLog ./log/PVZaehler-%Y.log PVZaehler:.*
attr FileLog_PVZaehler logtype text</nowiki>
und findet dort Einträge der Form
<nowiki>...
2014-01-20_16:09:55 PVZaehler counters.A: 282478
2014-01-20_16:09:55 PVZaehler counters.B: 139840
2014-01-20_16:14:58 PVZaehler counters.A: 282478
2014-01-20_16:14:58 PVZaehler counters.B: 139841
...</nowiki>
Wie man sieht, erscheinen für jeden der beiden Counter in diesem 1-Wire Device eine eigene Zeile mit dem aktuellen Wert des Zählers.
Da der erste S0-Zähler 2000 Impulse pro kWh liefert, ist der Wert für "counters.A" auch etwa das Doppelte von "counters.B", dessen
zugehöriger S0-Zähler ja nur 1000 Impulse pro kWh liefert.

Eigentlich wäre es wünschenswert,
nur eine Zeile mit beiden Werten zu loggen, diese mit der passenden Einheit Watt-Stunden (Wh) zu bezeichnen und auch noch die Summe der beiden Werte aufzuzeichnen.

Die "state" Zeile im Reading des Devices

[[Datei:owdevice-pvzaehler-reading.png]]

beinhaltet die Werte beider Counter, aber das "state" Reading verursacht laut [http://fhem.de/commandref.html#OWDevice CommandRef] keinen Event,
den man in einer FileLog Definition einfach verwenden könnte.

Es muss also etwas mehr getan werden. Die Idee ist, ein Dummy-Device zu definieren und dazu ein passendes Notify, das auf die "PVZaehler" Events reagiert und
den Wert an dieses Dummy-Device weitergibt, in dessen Filelog die Daten dann aufgezeichnet werden.

Im Einzelnen:
<code>define PVErtrag dummy </code>
definiert das Dummy-Device, das die Erträge der Anlage erhalten soll.

Mit
<nowiki>1: define notify_PVErtrag notify PVZaehler:counters\.A.* { \
2: my $a = ReadingsVal("PVZaehler","counters.A",0)/2 ;; \
3: my $b = ReadingsVal("PVZaehler","counters.B",0) ;; \
4: my $c = $a+$b ;; \
5: my $text = "WR1: $a Wh, WR2: $b Wh, Gesamt: $c Wh" ;; \
6: fhem ("set PVErtrag $text") ;; \
7: } </nowiki>
werden die Daten erzeugt und an das PVErtrag Device geschickt.

In Zeile 1 wird das Notify definiert: "PVZaehler" ist das Device, auf dessen Events
reagiert werden soll und "counters\.A.*" der reguläre Ausdruck, auf den das Notify reagieren soll. Der Punkt in "counters.A" ist mit einem Backslash maskiert,
da er sonst als Metazeichen für den regulären Ausdruck interpretiert werden würde. Das ".*" bezeichnet x-beliebigen Text.

Wenn nun also das PVZaehler-Device
einen Event verursacht, der die Zeichenkette "counters.A" enthält, dann wird der in geschweiften Klammern stehende Perl-Code ausgeführt.
Dabei dienen die Backslashes jeweils am Zeilenende als Hinweis für FHEM, dass der Perl-Code noch nicht zu Ende ist, sondern in der nächsten Zeile fortgeführt wird.
Ebenso sind entsprechend der CommandRef die Semikolons in der fhem.cfg verdoppelt.
Zeile 2 definiert eine Variable $a und weist ihr den Wert des "counters.A" geteilt durch 2 zu; in Zeile 3 erhält die Variable $b den Wert des "counters.B". In Zeile 4
werden die beiden Werte addiert und in Zeile 5 schliesslich zu einem Ausgabetext zusammengesetzt. Zeile 6 sendet dann diesen Ausgabetext an das PVErtrag Device.

Schliesslich wird mit
<nowiki>define FileLog_PVErtrag FileLog ./log/FileLog_PVErtrag-%Y-%m.log PVErtrag
attr FileLog_PVErtrag logtype text </nowiki>

das Filelog erzeugt, in dem die Daten abgelegt werden. Hier ein Auszug aus diesem FileLog:
<nowiki>...
2014-01-21_13:15:22 PVErtrag WR1: 141666 Wh, WR2: 140271 Wh, Gesamt: 281937 Wh
2014-01-21_13:20:22 PVErtrag WR1: 141677 Wh, WR2: 140282 Wh, Gesamt: 281959 Wh
2014-01-21_13:25:22 PVErtrag WR1: 141687.5 Wh, WR2: 140293 Wh, Gesamt: 281980.5 Wh
2014-01-21_13:30:22 PVErtrag WR1: 141697 Wh, WR2: 140302 Wh, Gesamt: 281999 Wh
2014-01-21_13:35:22 PVErtrag WR1: 141705.5 Wh, WR2: 140311 Wh, Gesamt: 282016.5 Wh
... </nowiki>

Stromzähler und 1-Wire, OWServer, OWDevice

2014-01-21T13:51:50Z

Mikezulugolf:

Dieser Artikel beschreibt eine Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

Das Ziel ist anstatt des monatlichen manuellen Ablesens des Einspeisezählers, eine granulare und automatisierte Aufzeichnung der Leistung einer Photovoltaikanlage zu erhalten.

[[Datei:fhemwiki-grafik-s0counter-und-onewire.gif]]

Zwischen die beiden Wechselrichter und dem Einspeisezähler sind je ein digitaler Stromzähler mit S0-Ausgang geschaltet.
Einer dieser Stromzähler liefert 2000 Impulse pro kWh, der andere 1000 Impulse pro kWh.

Diese beiden Stromzähler sind mit einem auf dem 1-Wire Baustein DS2423 basierenden Dual S0 Counter verbunden, der hier über einen
USB-Busmaster als serielles Interface mit einer Instanz eines OWServers verbunden ist.

In FHEM ist dieser OWServer wie folgt definiert:
<code>define myOWServer OWServer 192.168.1.12:4304</code>
Es wird hier ein OWServer definiert, der über die IP-Adresse 192.168.1.12 erreichbar ist und dort auf dem Port 4304 auf Anfragen lauscht.

Ist in FHEM das "autocreate" Flag gesetzt, dann findet FHEM den S0-Counter und erzeugt beispielsweise die folgenden Einträge:
<nowiki>define DS2423_58E50F000000 OWDevice 1D.58E50F000000 60
attr DS2423_58E50F000000 model DS2423
attr DS2423_58E50F000000 room OWDevice</nowiki>
Unter "DS2423_58E50F000000" kann man sich nicht direkt etwas vorstellen und anstatt alle 60 Sekunden ein Update zu holen, sollten auch 5 Minuten (=300 Sekunden) reichen. Daher wird das abgeändert zu:
<nowiki>define PVZaehler OWDevice 1D.58E50F000000 300
attr PVZaehler model DS2423
attr PVZaehler room OWDevice </nowiki>
Dann definiert man noch ein Logfile dazu:
<nowiki>define FileLog_PVZaehler FileLog ./log/PVZaehler-%Y.log PVZaehler:.*
attr FileLog_PVZaehler logtype text</nowiki>
und findet dort Einträge der Form
<nowiki>...
2014-01-20_16:09:55 PVZaehler counters.A: 282478
2014-01-20_16:09:55 PVZaehler counters.B: 139840
2014-01-20_16:14:58 PVZaehler counters.A: 282478
2014-01-20_16:14:58 PVZaehler counters.B: 139841
...</nowiki>
Wie man sieht, erscheinen für jeden der beiden Counter in diesem 1-Wire Device eine eigene Zeile mit dem aktuellen Wert des Zählers.
Da der erste S0-Zähler 2000 Impulse pro kWh liefert, ist der Wert für "counters.A" auch etwa das Doppelte von "counters.B", dessen
zugehöriger S0-Zähler ja nur 1000 Impulse pro kWh liefert.

Eigentlich wäre es wünschenswert,
nur eine Zeile mit beiden Werten zu loggen, diese mit der passenden Einheit Watt-Stunden (Wh) zu bezeichnen und auch noch die Summe der beiden Werte aufzuzeichnen.

Die "state" Zeile im Reading des Devices

[[Datei:owdevice-pvzaehler-reading.png]]

beinhaltet die Werte beider Counter, aber das "state" Reading verursacht laut CommandRef keinen Event,
den man in einer FileLog Definition einfach verwenden könnte.

Es muss also etwas mehr getan werden. Die Idee ist, ein Dummy-Device zu definieren und dazu ein passendes Notify, das auf die "PVZaehler" Events reagiert und
den Wert an dieses Dummy-Device weitergibt, in dessen Filelog die Daten dann aufgezeichnet werden.

Im Einzelnen:
<code>define PVErtrag dummy </code>
definiert das Dummy-Device, das die Erträge der Anlage erhalten soll.

Mit
<nowiki>1: define notify_PVErtrag notify PVZaehler:counters\.A.* { \
2: my $a = ReadingsVal("PVZaehler","counters.A",0)/2 ;; \
3: my $b = ReadingsVal("PVZaehler","counters.B",0) ;; \
4: my $c = $a+$b ;; \
5: my $text = "WR1: $a Wh, WR2: $b Wh, Gesamt: $c Wh" ;; \
6: fhem ("set PVErtrag $text") ;; \
7: } </nowiki>
werden die Daten erzeugt und an das PVErtrag Device geschickt.

In Zeile 1 wird das Notify definiert: "PVZaehler" ist das Device, auf dessen Events
reagiert werden soll und "counters\.A.*" der reguläre Ausdruck, auf den das Notify reagieren soll. Der Punkt in "counters.A" ist mit einem Backslash maskiert,
da er sonst als Metazeichen für den regulären Ausdruck interpretiert werden würde. Das ".*" bezeichnet x-beliebigen Text.

Wenn nun also das PVZaehler-Device
einen Event verursacht, der die Zeichenkette "counters.A" enthält, dann wird der in geschweiften Klammern stehende Perl-Code ausgeführt.
Dabei dienen die Backslashes jeweils am Zeilenende als Hinweis für FHEM, dass der Perl-Code noch nicht zu Ende ist, sondern in der nächsten Zeile fortgeführt wird.
Ebenso sind entsprechend der CommandRef die Semikolons in der fhem.cfg verdoppelt.
Zeile 2 definiert eine Variable $a und weist ihr den Wert des "counters.A" geteilt durch 2 zu; in Zeile 3 erhält die Variable $b den Wert des "counters.B". In Zeile 4
werden die beiden Werte addiert und in Zeile 5 schliesslich zu einem Ausgabetext zusammengesetzt. Zeile 6 sendet dann diesen Ausgabetext an das PVErtrag Device.

Schliesslich wird mit
<nowiki>define FileLog_PVErtrag FileLog ./log/FileLog_PVErtrag-%Y-%m.log PVErtrag
attr FileLog_PVErtrag logtype text </nowiki>

das Filelog erzeugt, in dem die Daten abgelegt werden. Hier ein Auszug aus diesem FileLog:
<nowiki>...
2014-01-21_13:15:22 PVErtrag WR1: 141666 Wh, WR2: 140271 Wh, Gesamt: 281937 Wh
2014-01-21_13:20:22 PVErtrag WR1: 141677 Wh, WR2: 140282 Wh, Gesamt: 281959 Wh
2014-01-21_13:25:22 PVErtrag WR1: 141687.5 Wh, WR2: 140293 Wh, Gesamt: 281980.5 Wh
2014-01-21_13:30:22 PVErtrag WR1: 141697 Wh, WR2: 140302 Wh, Gesamt: 281999 Wh
2014-01-21_13:35:22 PVErtrag WR1: 141705.5 Wh, WR2: 140311 Wh, Gesamt: 282016.5 Wh
... </nowiki>

Datei:Owdevice-pvzaehler-reading.png

2014-01-21T13:48:58Z

Mikezulugolf:

Stromzähler und 1-Wire, OWServer, OWDevice

2014-01-21T13:48:28Z

Mikezulugolf:

Dieser Artikel beschreibt eine Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

Das Ziel ist anstatt des monatlichen manuellen Ablesens des Einspeisezählers, eine granularere und automatisierte Aufzeichnung der Leistung einer Photovoltaikanlage zu erhalten.

[[Datei:fhemwiki-grafik-s0counter-und-onewire.gif]]

Zwischen die beiden Wechselrichter und dem Einspeisezähler sind je ein digitaler Stromzähler mit S0-Ausgang geschaltet.
Einer dieser Stromzähler liefert 2000 Impulse pro kWh, der andere 1000 Impulse pro kWh.

Diese beiden Stromzähler sind mit einem auf dem 1-Wire Baustein DS2423 basierenden Dual S0 Counter verbunden, der hier über einen
USB-Busmaster als serielles Interface mit einer Instanz eines OWServers verbunden ist.

In FHEM ist dieser OWServer wie folgt definiert:
<code>define myOWServer OWServer 192.168.1.12:4304</code>
Es wird hier ein OWServer definiert, der über die IP-Adresse 192.168.1.12 erreichbar ist und dort auf dem Port 4304 auf Anfragen lauscht.

Ist in FHEM das "autocreate" Flag gesetzt, dann findet FHEM den S0-Counter und erzeugt beispielsweise die folgenden Einträge:
<nowiki>define DS2423_58E50F000000 OWDevice 1D.58E50F000000 60
attr DS2423_58E50F000000 model DS2423
attr DS2423_58E50F000000 room OWDevice</nowiki>
Unter "DS2423_58E50F000000" kann man sich nicht direkt etwas vorstellen und anstatt alle 60 Sekunden ein Update zu holen, sollten auch 5 Minuten (=300 Sekunden) reichen. Daher wird das abgeändert zu:
<nowiki>define PVZaehler OWDevice 1D.58E50F000000 300
attr PVZaehler model DS2423
attr PVZaehler room OWDevice </nowiki>
Dann definiert man noch ein Logfile dazu:
<nowiki>define FileLog_PVZaehler FileLog ./log/PVZaehler-%Y.log PVZaehler:.*
attr FileLog_PVZaehler logtype text</nowiki>
und findet dort Einträge der Form
<nowiki>...
2014-01-20_16:09:55 PVZaehler counters.A: 282478
2014-01-20_16:09:55 PVZaehler counters.B: 139840
2014-01-20_16:14:58 PVZaehler counters.A: 282478
2014-01-20_16:14:58 PVZaehler counters.B: 139841
...</nowiki>
Wie man sieht, erscheinen für jeden der beiden Counter in diesem 1-Wire Device eine eigene Zeile mit dem aktuellen Wert des Zählers.
Da der erste S0-Zähler 2000 Impulse pro kWh liefert, ist der Wert für "counters.A" auch etwa das Doppelte von "counters.B", dessen
zugehöriger S0-Zähler ja nur 1000 Impulse pro kWh liefert.

Eigentlich wäre es wünschenswert,
nur eine Zeile mit beiden Werten zu loggen, diese mit der passenden Einheit Watt-Stunden (Wh) zu bezeichnen und auch noch die Summe der beiden Werte aufzuzeichnen.

Die "state" Zeile im Reading des Devices

[[Datei:owdevice-pvzaehler-reading.png]]

beinhaltet die Werte beider Counter, aber das "state" Reading verursacht laut CommandRef keinen Event,
den man in einer FileLog Definition einfach verwenden könnte.

Es muss also etwas mehr getan werden. Die Idee ist, ein Dummy-Device zu definieren und dazu ein passendes Notify, das auf die "PVZaehler" Events reagiert und
den Wert an dieses Dummy-Device weitergibt, in dessen Filelog die Daten dann aufgezeichnet werden.

Im Einzelnen:
<code>define PVErtrag dummy </code>
definiert das Dummy-Device, das die Erträge der Anlage erhalten soll.

Mit
<nowiki>1: define notify_PVErtrag notify PVZaehler:counters\.A.* { \
2: my $a = ReadingsVal("PVZaehler","counters.A",0)/2 ;; \
3: my $b = ReadingsVal("PVZaehler","counters.B",0) ;; \
4: my $c = $a+$b ;; \
5: my $text = "WR1: $a Wh, WR2: $b Wh, Gesamt: $c Wh" ;; \
6: fhem ("set PVErtrag $text") ;; \
7: } </nowiki>
werden die Daten erzeugt und an das PVErtrag Device geschickt.

In Zeile 1 wird das Notify definiert: "PVZaehler" ist das Device, auf dessen Events
reagiert werden soll und "counters\.A.*" der reguläre Ausdruck, auf den das Notify reagieren soll. Der Punkt in "counters.A" ist mit einem Backslash maskiert,
da er sonst als Metazeichen für den regulären Ausdruck interpretiert werden würde. Das ".*" bezeichnet x-beliebigen Text.

Wenn nun also das PVZaehler-Device
einen Event verursacht, der die Zeichenkette "counters.A" enthält, dann wird der in geschweiften Klammern stehende Perl-Code ausgeführt.
Dabei dienen die Backslashes jeweils am Zeilenende als Hinweis für FHEM, dass der Perl-Code noch nicht zu Ende ist, sondern in der nächsten Zeile fortgeführt wird.
Ebenso sind entsprechend der CommandRef die Semikolons in der fhem.cfg verdoppelt.
Zeile 2 definiert eine Variable $a und weist ihr den Wert des "counters.A" geteilt durch 2 zu; in Zeile 3 erhält die Variable $b den Wert des "counters.B". In Zeile 4
werden die beiden Werte addiert und in Zeile 5 schliesslich zu einem Ausgabetext zusammengesetzt. Zeile 6 sendet dann diesen Ausgabetext an das PVErtrag Device.

Schliesslich wird mit
<nowiki>define FileLog_PVErtrag FileLog ./log/FileLog_PVErtrag-%Y-%m.log PVErtrag
attr FileLog_PVErtrag logtype text </nowiki>

das Filelog erzeugt, in dem die Daten abgelegt werden. Hier ein Auszug aus diesem FileLog:
<nowiki>...
2014-01-21_13:15:22 PVErtrag WR1: 141666 Wh, WR2: 140271 Wh, Gesamt: 281937 Wh
2014-01-21_13:20:22 PVErtrag WR1: 141677 Wh, WR2: 140282 Wh, Gesamt: 281959 Wh
2014-01-21_13:25:22 PVErtrag WR1: 141687.5 Wh, WR2: 140293 Wh, Gesamt: 281980.5 Wh
2014-01-21_13:30:22 PVErtrag WR1: 141697 Wh, WR2: 140302 Wh, Gesamt: 281999 Wh
2014-01-21_13:35:22 PVErtrag WR1: 141705.5 Wh, WR2: 140311 Wh, Gesamt: 282016.5 Wh
... </nowiki>

Datei:Fhemwiki-grafik-s0counter-und-onewire.gif

2014-01-21T13:29:39Z

Mikezulugolf:

Stromzähler und 1-Wire, OWServer, OWDevice

2014-01-21T13:28:28Z

Mikezulugolf: Die Seite wurde neu angelegt: „Dieser Artikel beschreibt eine Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM. Das Ziel ist anstatt …“

Benutzer:Mikezulugolf

2014-01-20T13:24:56Z

Mikezulugolf: Die Seite wurde neu angelegt: „ == Über mich == * FHEM Benutzer seit 2010 (mit Tuxradio V1) ** anfänglich nur einige wenige FS20 Schaltaktoren ** dann einige wenige HMS Temperatur/Feuchtes…“