FHEMWiki - Benutzerbeiträge [de]

Waterkotte heat pump with Resümat CD4

2020-09-03T17:47:41Z

ZDX: Add prerequisites

{{Infobox Modul
|ModPurpose=Control / Extract information from Waterkotte Heat pumps with Resümat CD4 controller
|ModType=contrib
|ModCmdRef=WKRCD4
|ModForumArea=Sonstiges
|ModFTopic=17658
|ModTechName=98_WKRCD4.pm
|ModOwner=StefanStrobel ({{Link2FU|3960|Forum}} / [[Benutzer:StefanStrobel|Wiki]])
}}
WKRCD4 allows to control / communicate with older heat pumps from Waterkotte that have a control unit called Resümat CD4 with an RS232 serial interface. Newer heat pumps from Waterkotte typically have a modbus interface that can be controlled with module [[ModbusAttr]].
 
CD4 control units with software version 7000, 8000 or 8011 can be controlled with [https://forum.fhem.de/index.php/topic,83006.msg886622.html#msg886622 another version] of the WKRCD4 module.

== Availability ==
The module has been checked in to the contrib area.

== Prerequisites ==
This module requires Device::SerialPort or Win32::SerialPort module. Make sure to set "Modem-Klingelzeichen" and "Fremdzugriff" to the lowest possible value.

== Define ==
<pre>
define <name> WKRCD4 <devicename@speed> <Interval>
</pre>
The module connects to the heat pump through a serial interface and actively requests data from the heat pump every <Interval> seconds

=== Example:===

<pre>
define WP WKRCD4 /dev/dualser0@9600 60
attr WP stateFormat Status
attr WP event-min-interval .*:3600
attr WP event-on-change-reading .*
</pre>

== Configuration of the module ==
Apart from the serial interface and the interval there is nothing that needs to be defined.

== Get-Commands ==
There are only two parameters for which an explicit GET has been implemented. Most values are just readings that are automatically requested:
<pre>
Hzg-TempBasisSoll
WW-Temp-Soll
</pre>

== Set-Commands ==
There is only one parameter that can be changed:
<pre>
Hzg-TempBasisSoll
</pre>

== Supported readings ==
The module extracts the following readings from the heat pump:
<pre>
Versions-Nummer
Temp-Aussen
Temp-Ruecklauf-Soll
Temp-Ruecklauf
Temp-Vorlauf
Temp-WW-Soll
Temp-WW
Temp-Raum
Temp-WQuelle-Ein
Temp-WQuelle-Aus
Temp-Verdampfer
Temp-Kondensator
Temp-Saugleitung
Druck-Verdampfer
Druck-Kondensator
Hzg-TempEinsatz
Hzg-TempBasisSoll
Hzg-KlSteilheit
Hzg-KlBegrenz
Hzg-TempRlSoll
Hzg-TempRlIst
Hzg-TmpRaumSoll
Hzg-RaumEinfluss
Hzg-ExtAnhebung
Hzg-Zeit-Ein
Hzg-Zeit-Aus
Hzg-AnhebungEin
Hzg-AnhebungAus
Hzg-St2Begrenz
Hzg-Hysterese
Hzg-PumpenNachl
Klg-Abschaltung
Klg-Temp-Einsatz
Klg-TeBasisSoll
Klg-KlSteilheit
Klg-KlBegrenz
Klg-KlSollwert
Klg-Temp-Rl
Ww-Abschaltung
Ww-Zeit-Ein
Ww-Zeit-Aus
Ww-Temp-Ist
Ww-Temp-Soll
Ww-Hysterese
Uhrzeit
Datum
BetrStundenKompressor
BetrStundenHzgPu
BetrStundenWwPu
BetrStundenSt2
Zeit
SetBetriebsMode
Display-Zeile-1
Display-Zeile-2
Status-Gesamt
Status-Heizung
Status-Kuehlung
Mode-Heizung
Mode-Kuehlung
Mode-Warmwasser
Heizung
Kuehlung
Warmwasser
</pre>

== Attributes ==
;do_not_notify
: ...
;readingFnAttributes
: ... [[Kategorie:Other Components]] [[Kategorie:Heizungssteuerung]]

Acer Beamer mit RS232

2020-06-09T18:22:56Z

ZDX: Beispieldefinitionen hinzugefügt

{{Infobox Modul
|ModPurpose=Ermöglicht die Steuerung von Beamern der Marke Acer über das RS232-Interface
|ModType=x
|ModCmdRef=AcerBeamer_RS232
|ModForumArea=Multimedia
|ModFTopic=95757
|ModTechName=70_AcerBeamer_RS232.pm
|ModOwner=mwllgr ({{Link2FU|34515|Forum}})
}}
[[Acer Beamer mit RS232]] können mit dem Modul 70_AcerBeamer_RS232.pm gesteuert werden. Auch Informationen wie z.B. der derzeitige Eingang können abgerufen werden.

== Definition ==
<pre>
define <Name> AcerBeamer_RS232 <device@baudrate> <Interval>
</pre>
Wenn keine Baud-Rate angegeben ist wird standardmäßig 9600 verwendet - dies sollte für die meisten Beamer auch korrekt sein.
Das Modul überprüft alle ''<Interval>''-Sekunden (wenn nicht angegeben: 60) ob der Beamer derzeit eingeschaltet ist oder nicht und setzt das entsprechende Reading.

'''Beispieldefinitionen:'''

Linux<pre>
define Beamer AcerBeamer_RS232 /dev/ttyUSB0@9600 60
</pre>
Windows<pre>
define Beamer AcerBeamer_RS232 COM1@9600 60
</pre>
== Readings / Get-Befehle ==
* lampHours - Betriebsstunden der Lampe
* manufacturer - Hersteller/Marke des Beamers
* source - Derzeit ausgewählter Eingang
* presence - absent/present für aus/ein (Nicht direkt als get)
* state - off/on (Nicht direkt als get)

== Set-Befehle ==
* power
** on
** off

* quickSettings
** 16:9
** 4:3
** brightness
** colorRgb
** colorTemp
** contrast
** eKey
** keystone
** language

* remoteControl
** up
** down
** left
** right
** freeze
** hide
** menu
** mute
** zoom
** volUp
** volDown

* source
** auto
** resync
** dsub
** hdmi
** composite
** svideo

== Bekannte Probleme ==
Wird ein Befehl abgesetzt während eine zyklische Power-Abfrage läuft so kann es unter Umständen passieren, dass der Status des Beamers fälschlicherweise auf "off" gesetzt wird.

Bei einigen Beamern funktionieren manche Befehle eventuell nicht, bitte im Forenthread melden, wenn Probleme auftreten.

== Links ==
[http://bilder.hifi-forum.de/medium/226620/pinbelegung_195544.jpg Pinbelegung für das benötige Kabel], hifi-forum.de

[[Kategorie:Gerätemodul]]
[[Kategorie:Unterhaltungselektronik]]

Acer Beamer mit RS232

2020-04-14T21:40:16Z

ZDX: Forenbenutzer geändert

{{Infobox Modul
|ModPurpose=Ermöglicht die Steuerung von Beamern der Marke Acer über das RS232-Interface
|ModType=x
|ModCmdRef=AcerBeamer_RS232
|ModForumArea=Multimedia
|ModFTopic=95757
|ModTechName=70_AcerBeamer_RS232.pm
|ModOwner=mwllgr ({{Link2FU|34515|Forum}})
}}
[[Acer Beamer mit RS232]] können mit dem Modul 70_AcerBeamer_RS232.pm gesteuert werden. Auch Informationen wie z.B. der derzeitige Eingang können abgerufen werden.

== Definition ==
<pre>
define <Name> AcerBeamer_RS232 <device@baudrate> <Interval>
</pre>
Wenn keine Baud-Rate angegeben ist wird standardmäßig 9600 verwendet - dies sollte für die meisten Beamer auch korrekt sein.
Das Modul überprüft alle ''<Interval>''-Sekunden (wenn nicht angegeben: 60) ob der Beamer derzeit eingeschaltet ist oder nicht und setzt das entsprechende Reading.

== Readings / Get-Befehle ==
* lampHours - Betriebsstunden der Lampe
* manufacturer - Hersteller/Marke des Beamers
* source - Derzeit ausgewählter Eingang
* presence - absent/present für aus/ein (Nicht direkt als get)
* state - off/on (Nicht direkt als get)

== Set-Befehle ==
* power
** on
** off

* quickSettings
** 16:9
** 4:3
** brightness
** colorRgb
** colorTemp
** contrast
** eKey
** keystone
** language

* remoteControl
** up
** down
** left
** right
** freeze
** hide
** menu
** mute
** zoom
** volUp
** volDown

* source
** auto
** resync
** dsub
** hdmi
** composite
** svideo

== Bekannte Probleme ==
Wird ein Befehl abgesetzt während eine zyklische Power-Abfrage läuft so kann es unter Umständen passieren, dass der Status des Beamers fälschlicherweise auf "off" gesetzt wird.

Bei einigen Beamern funktionieren manche Befehle eventuell nicht, bitte im Forenthread melden, wenn Probleme auftreten.

== Links ==
[http://bilder.hifi-forum.de/medium/226620/pinbelegung_195544.jpg Pinbelegung für das benötige Kabel], hifi-forum.de

[[Kategorie:Gerätemodul]]
[[Kategorie:Unterhaltungselektronik]]

ModbusAttr

2020-01-05T15:07:53Z

ZDX: /* All Attributes */

{{Infobox Modul
|ModPurpose=Extract information from devices with a Modbus interface or send information to such devices
|ModType=d
|ModCmdRef=ModbusAttr
|ModForumArea=Sonstiges
|ModFTopic=25315
|ModTechName=98_ModbusAttr.pm
|ModOwner=StefanStrobel ({{Link2FU|3960|Forum}} / [[Benutzer:StefanStrobel|Wiki]])
}}

[[ModbusAttr]] uses the low level Modbus module 98_[[Modbus]].pm to provide a generic Modbus module (as master, slave, relay or passive listener)
that can be configured by attributes similar to the way HTTPMOD works for devices with a web interface.

ModbusAttr can be used as a Modbus master that queries data from other devices over a serial RS232 / RS485 or TCP connection,
it can be used as a Modbus slave that can make readings of Fhem devices available via Modbus to external Modbus masters,
it can act as a Modbus relay that receives requests over one connection and forwards them over another connection (e.g. from Modbus TCP to serial Modbus RTU)
or it can passively listen to other devices that communicate over a serial RS485 connection and extract readings from the objects it sees.
The supported protocols are Modbus RTU, Modbus ASCII or Modbus TCP.

There are several attributes that modify the way data objects are converted before they are stored in readings or sent to a device. Data can be modified by a perl expression defined in an atribute, formatted with a format string defined in another attribute or mapped to a table defined in an attribute.

Readings can directly correspond to one data object or they can span several objects. A float value for example might be stored in two input or holding registers in the Modbus device. By specifying attributes that define the length of a reading in objects and by specifying the unpack code to get from a raw string to perl variables, all these cases can be described by attributes and no perl coding is necessary.

== Availability ==
The module has been checked in.

== Prerequisites ==
This module uses the [[Modbus|Modbus base module 98_Modbus.pm]] which uses the DevIO module

== Define as Modbus master ==

<pre>
define <iodevice> Modbus /dev/device@baudrate,bits,parity,stop
define <name> ModbusAttr <Id> <Interval> <RTU|ASCII>
</pre>
or
<pre>
define <name> ModbusAttr <Id> <Interval> <Address:Port> <RTU|ASCII|TCP>
</pre>

In the first case the module connects to the external Modbus device with Modbus Id <Id> through a serial modbus device (RS232 or RS485).

In the second case it connects directly through Modbus TCP or Modbus RTU or ASCII over TCP.

If <Interval> is not 0 then the module actively requests data from that device every <Interval> seconds.

The objects that the module should request and the readings it should create from these objects have to be defined with attributes (see below).
These attributes will define a mapping from so called "coils", "digital inputs", "input registers" or "holding registers" of the external device to readings inside Fhem together with the data type and format of the values.
Interval can be 0 in which case the Module only requests data when it is triggered with a Fhem get-Command.
With this mode a Fhem installation can for example query sensor data from a heating system, energy meter or solar power installation if these systems offer a Modbus interface.

Examples:

<pre>
define ModbusLine Modbus /dev/ttyUSB1@9600
define WP ModbusAttr 1 60
</pre>
Define WP as a Modbus master that communicates through the Modbus serial interface device named ModbusLine. The protocol defaults to Modbus RTU

<pre>
define ModbusLine Modbus /dev/ttyUSB1@9600
define WP ModbusAttr 20 0 ASCII
</pre>
Define WP as a Modbus master that communicates through the Modbus serial interface device named ModbusLine with Modbus ASCII.
Use Modbus Id 20 and don't query the device in a defined interval. Instead individual SET / GET options have to be used for communication.

<pre>
define WP ModbusAttr 5 60 192.168.1.122:502 TCP
</pre>
to talk Modbus TCP to a device with IP-Address 192.168.1.122 and the reserved port for Modbus TCP 502
Note that for Modbus over a TCP connection you don't need a basic Modbus device for the interface like ModbusLine above.

<pre>
define WP ModbusAttr 3 60 192.168.1.122:8000 RTU
</pre>
to talk Modbus RTU over TCP and use the port number 8000

== Define as Modbus slave ==

<pre>
define <name> ModbusAttr <Id> slave
</pre>
or
<pre>
define <name> ModbusAttr <Id> slave <Address:Port> <RTU|ASCII|TCP>
</pre>

The module waits for connections from other Modbus masters. It will respond to their requests if the requests contain the given Modbus <Id>
To provide data with Modbus to external Modbus masters a mapping needs to be defined using attributes.
These attributes will define a mapping from Readings inside Fhem to so called "coils", "digital inputs", "input registers" or "holding registers" and their Modbus object address together with the data type and format of the values.
With this mode a Fhem installation can for example supply data to a PLC that actively reads data from Fhem or writes data to Fhem readings.

Examples:

<pre>
define MRS485 Modbus /dev/ttyUSB2@9600,8,E,1
define Data4PLC ModbusAttr 1 slave
</pre>
Define Data4PLC as a Modbus slave that communicates through the Modbus serial interface device named MRS485 to listen for Modbus requests with Id 1. The protocol defaults to Modbus RTU

<pre>
define MRS485 Modbus /dev/ttyUSB2@9600,8,E,1
define Data4PLC ModbusAttr 20 slave ASCII
</pre>
to listen for Modbus requests with Id 20 with Modbus ASCII.

<pre>
define Data4PLC ModbusAttr 5 slave 192.168.1.2:502 TCP
</pre>
to start listening to TCP port 502 on the local address 192.168.1.2. Modbus TCP will be used as protocol and Requests with Modbus Id 5 will be answered.

Please be aware that opening a port number smaller than 1024 needs root permissions on Unix devices. So it is probably better to use a non standard port number above 1024 instead.

<pre>
define Data4PLC ModbusAttr 3 slave 192.168.1.2:8000 RTU
</pre>
to listen to the local port 8000 and talk Modbus RTU over TCP

== Define as Modbus passive listener ==

<pre>
define <name> ModbusAttr <Id> passive <RTU|ASCII|TCP>
</pre>

The module listens on a serial (RS485) connection for modbus communication with the given Modbus <Id> and extracts readings. It does not send requests by itself but waits for another master to communicate with a slave. So only objects that the other master requests can be seen by Fhem in this configuration.
The objects that the module recognizes and the readings that it should create from these objects have to be defined with attributes (see below) in the same way as for a Modbus master.
These attributes will define a mapping from so called "coils", "digital inputs", "input registers" or "holding registers" of the external device to readings inside Fhem together with the data type and format of the values.
With this mode a Fhem installation can for example Listen to the communication between an energy counter as slave and a solar control system as master if they use Modbus RTU over RS485. Since only one Master is allowed when using Modbus over serial lines, Fhem can not be master itself. As a passive listener it can however see when the master queries e.g. the current power consumption and then also see the reply from the energy meter and store the value in a Fhem reading.

Examples:

<pre>
define MB-485 Modbus /dev/ttyUSB2
define WP ModbusAttr 1 passive
</pre>
to passively listen for Modbus requests and replies with Id 1 over a serial interface managed by an already defined basic modbus device named MB-485. The protocol defaults to Modbus RTU

<pre>
define MB-485 Modbus /dev/ttyUSB2
define WP ModbusAttr 20 passive ASCII
</pre>
to passivel listen for Modbus requests / replies with Id 20 and Modbus ASCII.

== Define as Modbus relay ==

<pre>
define <name> ModbusAttr <Id> relay to <FhemMasterDevice>
</pre>
or
<pre>
define <name> ModbusAttr <Id> relay <Address:Port> <RTU|ASCII|TCP> to <FhemMasterDevice>
</pre>

The module waits for connections from other Modbus masters. It will forward requests if they match the given Modbus <Id> to an already defined Modbus Master device inside Fhem which will send them to its defined slave, take the reply and the pass it back to the original Master.
With this mode a Fhem installation can for example be used in front of a device that only speaks Modbus RTU over RS485 to make it available via Modbus TCP over the local network.

Examples:

<pre>
define MB-485 Modbus /dev/ttyUSB2
define Heating ModbusAttr 22 0
define Relay ModbusAttr 33 relay 192.168.1.2:1502 TCP to Heating
</pre>
Defines MB-485 as a base device for the RS-485 communication with a heating system,
defines Heating as a Modbus Master to communicate with the Heating and its Modbus ID 22,
and then defines the relay which listens to the local IP address 192.168.1.2, TCP port 1502, Modbus Id 33 and protocol Modbus-TCP.
Requests coming in through Modbus TCP and port 1502 are then translated to Modbus RTU and forwarded via RS-485 to the heating system with Modbus Id 22.

or (unlikely)
<pre>
define MB-232 Modbus /dev/ttyUSB2@19200
define Solar ModbusAttr 7 0 192.168.1.122:502 RTU
define PLC2NetRelay ModbusAttr 1 ASCII relay to Solar
</pre>
Defines MB-232 as a base device for the RS-232 communication with a PLC as Modbus master,
defines Solar as a Modbus Master to communicate with Modbus TCP to a Solar power system at IP Adrress 192.168.1.122 and its Modbus ID 7,
and then defines the PLC2NetRelay as a relay which listens to Modbus-ASCII requests over the serial RS-232 link from a PLC to Modbus ID 1.
Requests to Modbus Id 1 coming in through the serial link are then translated to Modbus TCP and forwarded over the network to the solar power system with Modbus Id 7.

== Configuration of the module as master or passive listener ==

Data objects (holding registers, input registers, coils or discrete inputs) are defined using attributes.
If Fhem is Modbus master or passive listener, the attributes assign data objects of external devices (heating systems, power meters, PLCs or other) with their register addresses to readings inside fhem and control how these readings are calculated from the raw values and how they are formatted.
Please be aware that Modbus does not define common data types so the representation of a value can be very different from device to device. One device might make a temperature value avaliable as a floating point value that is stored in two holding resgisters, another device might store the temperature multiplied with 10 as an signed integer in one register. Even the order of bytes can vary.
Therefore it is typically necessary to specify the data representation as a Perl unpack code.
A Modbus master can also write values to Objects in the device and attributes define how this is done.

Example for a Modbus master or passive configuration:
<pre>
define PWP ModbusAttr 5 30
attr PWP obj-h256-reading Temp_Wasser_ein
attr PWP obj-h256-expr $val/10

attr PWP obj-h258-reading Temp_Wasser_Aus
attr PWP obj-h258-expr $val/10

attr PWP obj-h262-reading Temp_Luft
attr PWP obj-h262-expr $val / 10

attr PWP obj-h770-reading Temp_Soll
attr PWP obj-h770-expr $val / 10
attr PWP obj-h770-set 1
attr PWP obj-h770-setexpr $val * 10
attr PWP obj-h770-max 32
attr PWP obj-h770-min 10
attr PWP obj-h770-hint 8,10,20,25,28,29,30,30.5,31,31.5,32

attr PWP dev-h-combine 5
attr PWP dev-h-defPoll 1
attr PWP dev-h-defUnpack n

attr PWP room Pool-WP
attr PWP stateFormat {sprintf("%.1f Grad", ReadingsVal($name,"Temp_Wasser_Ein",0))}
attr PWP webCmd Temp_Soll
</pre>

Attributes to define data objects start with obj- followed by a code that identifies the type and address
of the data object.

Modbus devices offer the following types of data objects:

;holding registers (16 bit objects that can be read and written)
;input registers (16 bit objects that can only be read)
;coils (single bit objects that can be read and written)
;discrete inputs (single bit objects that can only be read)

The module uses the first character of these data object types to define attributes.
Thus h770 refers to a holding register with the decimal address 770 and c120 refers to a coil with address 120.
The address has to be specified as pure decimal number. The address counting starts at address 0

Please note that the documentation for devices sometimes uses different numbering. They might start counting with one instead of zero so if a voltage value is stored in input register number 107 according to the documentation of the device, it might technically mean register number 106 (in the Modbus protocol specification addresses start with 0).
Also some vendors use hexadecimal descriptions of their register addresses. So input register 107 might be noted as hex and means 263 or even 262 as decimal address.

<pre>
attr PWP obj-h258-reading Temp_Wasser_Aus
</pre>
defines a reading with the name Temp_Wasser_Aus that is read from the Modbus holding register at address 258.
With the attribute ending on <code>-expr</code> you can define a perl expression to do some conversion or calculation on the raw value read from the device.
In the above example the raw value has to be devided by 10 to get the real value. If the raw value is also the final value then no <code>-expr</code> attribute is necessary.

An object attribute ending on <code>-set</code> creates a fhem set option.
In the above example the reading Temp_Soll can be changed to 12 degrees by the user with the fhem command <code>set PWP Temp_Soll 12</code>
The object attributes ending on <code>-min</code> and <code>-max</code> define min and max values for input validation
and the attribute ending on <code>-hint</code> will tell fhem to create a selection list so the user can graphically select the defined values.

To define general properties of the device you can specify attributes starting with <code>dev-</code>.
E.g. with <code>dev-timing-timeout</code> you can specify the timeout when waiting for a response from the device.
With <code>dev-h-</code> you can specify several default values or general settings for all holding registers
like the function code to be used when reading or writing holding registers.
These attributes are optional and the module will use defaults that work in most cases.
<code>dev-h-combine 5</code> for example allows the module to combine read requests to objects having an address that differs 5 or less into one read request.
Without setting this attribute the module will start individual read requests for each object.
Typically the documentation for the modbus interface of a given device states the maximum number of objects that can be read in one function code 3 request.
<code>dev-h-defUnpack n</code> means that the values in this example that the values are stored as unsigned short (16-bit) in "network" (big-endian) order. This is only one possibility of many. An integer value might be signed instead of unsigned or it might use different byte ordering (e.g. unpack codes v or s).

== Handling Data Types ==

The Modbus protocol does not define data types. If the documentation of a device states that for example the current temperature is stored in holding register 102 this leaves room for many interpretations. Not only can the address 102 mean different things (actually decimal 102 or rather 101 if the vendor starts counting at 1 instead of 0 or even 257 or 258 if the vendor used hexadecimal addresses in his documentation ) also the data representation can be many different things. As in every programming language, there are many ways to represent numbers. They can be stored signed or unsigned, they can be integers or floating point numbers, the byte-order can be "big endian" or "small endian", the value can be stored in one holding register or in two holding registers (floating point numbers typically take four bytes which means two holding registers).
The Modbus module allows flexible configuration of data representations be assigning a Perl unpack-code, a length, a Perl Expression, and the register ordering. The following example illustrates how this can be done:
<pre>
attr PWP obj-h338-reading Pressure
attr PWP obj-h338-len 2
attr PWP obj-h338-unpack f>
attr PWP obj-h338-revRegs 1
attr PWP obj-h338-format %.2f
</pre>
In This example a floating point value for the reading "Pressure" is read from the holding registers starting at address 338.
The value occupies 32 Bits and is therefore stored in two registers. The Perl pack code to use is f> which means a native single precision float in big endian format (byte order). With revRegs the module is instructed to reverse the order of the registers directly after reading. The format specification then defines how the value is formatted into a reading - in this case with two digits after the comma. See http://perldoc.perl.org/functions/pack.html for Perl pack / unpack codes and http://perldoc.perl.org/functions/sprintf.html for format specifications.

If you need to read / write many objects for a device, defining all these parameters each time is not elegant. The Modbus module therefore offers twi ways to simplify this task:
You can define defaults for every type of object or you can define your own data types once and then refer to them.
This exampe shows how defaults can be specified for holding registers and input registers:
<pre>
attr PWP dev-h-defUnpack f>
attr PWP dev-h-defLen 2
attr PWP dev-h-defRevRegs 1
attr PWP dev-h-defFormat %.2f

attr PWP dev-i-defUnpack n
attr PWP dev-i-defLen 1
</pre>

The next example shows how you can define your own data types and then apply them to objects:
<pre>
attr WP dev-type-VT_R4-format %.1f
attr WP dev-type-VT_R4-len 2
attr WP dev-type-VT_R4-revRegs 1
attr WP dev-type-VT_R4-unpack f>

attr WP obj-h1234-reading Temp_In
attr WP obj-h1234-type VT_R4
attr WP obj-h1236-reading Temp_Out
attr WP obj-h1236-type VT_R4
</pre>
This example defines a data type with the name VT_R4 which uses an unpack code of f>, length 2 and reversed register ordering. It then assigns this Type to the objects Temp_In and Temp_Out.

== Configuration of the module as Modbus slave ==

Data objects that the module offers to external Modbus masters (holding registers, input registers, coils or discrete inputs) are defined using attributes.
If Fhem is Modbus slave, the attributes assign readings of Fhem devices to Modbus objects with their addresses and control how these objects are calculated from the reading values that exist in Fhem.
It is also possible to allow an external Modbus master to send write function codes and change the value of readings inside Fhem.

Example for a Modbus slave configuration:
<pre>
define MRS485 Modbus /dev/ttyUSB2@9600,8,E,1
define Data4PLC ModbusAttr 1 slave
attr Data4PLC IODev MRS485

attr Data4PLC obj-h256-reading THSensTerrasse:temperature
attr Data4PLC obj-h256-unpack f
attr Data4PLC obj-h256-len 2

attr Data4PLC obj-h258-reading THSensTerrasse:humidity
attr Data4PLC obj-h258-unpack f
attr Data4PLC obj-h258-len 2

attr Data4PLC obj-h260-reading myDummy:limit
attr Data4PLC obj-h260-unpack n
attr Data4PLC obj-h260-len 1
attr Data4PLC obj-h260-allowWrite 1
</pre>

In this example Fhem allows an external Modbus master to read the temperature of a Fhem device named THSensTerrasse through holding register 256 and the humidity of that Fhem device through holding register 258. Both are encoded as floting point values that span two registers.
The master can also read but also write the reading named limit of the device myDummy.

== Set-Commands ==
can be defined for holding registers and coils by using attributes.

Every object for which an attribute like <code>obj-xy-set</code> is set to 1 will create a valid set option.

Additionally the attribute <code>enableControlSet</code> enables the set options <code>interval</code>, <code>stop</code>, <code>start</code>, <code>reread</code> as well as <code>scanModbusObjects</code>, <code>scanStop</code> and <code>scanModbusIds</code> (for devices connected with RTU / ASCII over a serial line).

;<code>interval <Interval></code>
:modifies the interval that was set during define.

;<code>stop</code>
:stops the interval timer that is used to automatically poll objects through Modbus.

;<code>start</code>
:starts the interval timer that is used to automatically poll objects through Modbus.
:If an interval is specified during the define command then the interval timer is started automatically.
:However if you stop it with the command <code>set <mydevice> stop</code>
:then you can start it again with <code>set <mydevice> start</code>.

;<code>reread</code>
:causes a read of all objects that are set to be polled in the defined interval. The interval timer is not modified.

;<code>scanModbusObjects <startObj> - <endObj> <reqLen></code>
:scans the device objects and automatically creates attributes for each reply it gets.
:This might be useful for exploring devices without proper documentation.
:The following example starts a scan and queries the holding registers with addresses between 100 and 120.
:<code>set MyModbusAttrDevice scanModbusObjects h100-120</code> 
:For each reply it gets, the module creates a reading like
:<code>scan-h100 hex=0021, string=.!, s=8448, s>=33, S=8448, S>=33</code> 
:the representation of the result as hex is 0021 and
:the ASCII representation is .!. s, s>, S and S> are different representations with their Perl pack-code.

;<code>scanModbusIds <startId> - <endId> <knownObj></code>
:scans for Modbus Ids on an RS485 Bus. The following set command for example starts a scan: 
:<code>set Device scanModbusId 1-7 h770</code> 
:since many Modbus devices don't reply at all if an object is requested that does not exist,
:scanModbusId needs the adress of an object that is known to exist.
:If a device with Id 5 replies to a read request for holding register 770, a reading like the following will be created:
:<code>scanId-5-Response-h770 hex=0064, string=.d, s=25600, s>=100, S=25600, S>=100</code>
;<code>scanStop</code>
:stops any running scans.
;saveAsModule <name>
:experimental: saves the definitions of obj- and dev- attributes in a new fhem module file as /tmp/98_ModbusGen<name>.pm.
:if this file is copied into the fhem module subdirectory (e.g. /opt/fhem/FHEM) and fhem is restarted then instead of defining a device
:as ModbusAttr with all the attributes to define objects, you can just define a device of the new type ModbusGen<name> and all the
:objects will be there by default. However all definitions can still be changed / overriden with the attribues defined in ModbusAttr if needed.

== Get-Commands ==

Every reading can be manually requested by a Get.
Internally a Get command triggers the corresponding Modbus request to the device and the module then interprets the data and sets the right Fhem readings. To avoid huge option lists in FHEMWEB, the objects visible as Get in FHEMWEB can be defined by setting an attribute <code>obj-xy-showGet</code> to 1.

== All Attributes ==

;readingFnAttributes
:the usual Fhem attributes for all devices

;alignTime
:Aligns each periodic read request for the defined interval to this base time.
:This is typcally something like 00:00 (see the Fhem at command)

;enableControlSet
:enables the built in set commands like interval, stop, start and reread (see above)

the following list of attributes can be applied to any data object by specifying the objects type and address in the variable part.
For many attributes you can also specify default values per object type (see dev- attributes later) or you can specify an object attribute without type and address (e.g. obj-len) which then applies as default for all objects:

;obj-[cdih][1-9][0-9]*-reading
:define the name of a reading that corresponds to the Modbus data object of type c,d,i or h and a decimal address (e.g. obj-h225-reading).

;obj-[cdih][1-9][0-9]*-name
:defines an optional internal name of this data object (this has no meaning for fhem and serves mainly documentation purposes.

;obj-[cdih][1-9][0-9]*-set
:if set to 1 then this data object can be changed (works only for holding registers and coils since discrete inputs and input registers can not be modified by definition.

;obj-[cdih][1-9][0-9]*-min
:defines a lower limit to the value that can be written to this data object. This ist just used for input validation.

;obj-[cdih][1-9][0-9]*-max
:defines an upper limit to the value that can be written to this data object. This ist just used for input validation.

;obj-[cdih][1-9][0-9]*-hint
:this is used for set options and tells fhemweb what selection to display for the set option (list or slider etc.)

;obj-[cdih][1-9][0-9]*-expr
:defines a perl expression that converts the raw value read from the device.

;obj-[cdih][1-9][0-9]*-ignoreExpr
:defines a perl expression that returns 1 if a value should be ignored and the existing reading should not be modified

;obj-[cdih][1-9][0-9]*-map
:defines a map to convert values read from the device to more convenient values when the raw value is read from the device or back when the value to write has to be converted from the user value to a raw value that can be written. Example: 0:mittig, 1:oberhalb, 2:unterhalb

;obj-[cdih][1-9][0-9]*-setexpr
:defines a perl expression that converts the user specified value in a set to a raw value that can be sent to the device. This is typically the inversion of -expr above.

;obj-[cdih][1-9][0-9]*-format
:defines a format string to format the value read e.g. %.1f

;obj-[cdih][1-9][0-9]*-len
:defines the length of the data object in registers. It defaults to 1. Some devices store 32 bit floating point values in two registers. In this case you can set this attribute to two.

;obj-[cdih][1-9][0-9]*-unpack
:defines the unpack code to convert the raw data string read from the device to a reading. For an unsigned integer in big endian format this would be "n", for a signed 16 bit integer in big endian format this would be "s>" and for a 32 bit big endian float value this would be "f>". (see the perl documentation of the pack function).

;obj-[cdih][1-9][0-9]*-revRegs
:this is only applicable to objects that span several input registers or holding registers.
:when they are read then the order of the registers will be reversed before
:further interpretation / unpacking of the raw register string.
:The same happens before the object is written with a set command.

;obj-[cdih][1-9][0-9]*-bswapRegs
:this is applicable to objects that span several input or holding registers.
:After the registers have been read and before they are writtem,
:all 16-bit values are treated big-endian and are reversed to little-endian by swapping the two 8 bit bytes.
:This functionality is most likely used for reading (ASCII) strings from the device
:that are stored as big-endian 16-bit values.
:example: original reading is "324d3130203a57577361657320722020". After applying bswapRegs,
:the value will be "4d3230313a2057576173736572202020" which will result in the ASCII string
:"M201: WWasser ".
:Should be used with "(a*)" as -unpack value.

;obj-[cdih][1-9][0-9]*-decode
:defines an encoding to be used in a call to the perl function decode to convert the raw data string
:read from the device to a reading.
:This can be used if the device delivers strings in an encoding like cp850 instead of utf8.

;obj-[cdih][1-9][0-9]*-encode
:defines an encoding to be used in a call to the perl function encode to convert the raw data string
:read from the device to a reading.
:This can be used if the device delivers strings in an encoding like cp850 and after decoding it you want to reencode it to e.g. utf8.

;obj-[cdih][1-9][0-9]*-showGet
:every reading can also be requested by a get command. However these get commands are not automatically offered in fhemweb. By specifying this attribute, the get will be visible in fhemweb.

;obj-[cdih][1-9][0-9]*-poll
:if set to 1 then this obeject is included in the cyclic update request as specified in the define command. If not set, then the object can manually be requested with a get command, but it is not automatically updated each interval. Note that this setting can also be specified as default for all objects with the dev- atributes described later.

;obj-[cdih][1-9][0-9]*-polldelay
:this attribute allows to poll objects at a lower rate than the interval specified in the define command. you can either specify a time in seconds or number prefixed by "x" which means a multiple of the interval of the define command. if you specify a normal numer then it is interpreted as minimal time between the last read and another automatic read. Please note that this does not create an individual interval timer. Instead the normal interval timer defined by the interval of the define command will check if this reading is due or not yet. So the effective interval will always be a multiple of the interval of the define.

;dev-([cdih]-)*read
:specifies the function code to use for reading this type of object. The default is 3 for holding registers, 1 for coils, 2 for discrete inputs and 4 for input registers.

;dev-([cdih]-)*write
:specifies the function code to use for writing this type of object. The default is 6 for holding registers and 5 for coils. Discrete inputs and input registers can not be written by definition.

;dev-([cdih]-)*combine
:defines how many adjacent objects can be read in one request. If not specified, the default is 1

;dev-([cdih]-)*defLen
:defines the default length for this object type. If not specified, the default is 1

;dev-([cdih]-)*defFormat
:defines a default format string to use for this object type in a sprintf function on the values read from the device.

;dev-([cdih]-)*defExpr
:defines a default Perl expression to use for this object type to convert raw values read.

;dev-([cdih]-)*defIgnoreExpr
:defines a default Perl expression to decide when values should be ignored.

;dev-([cdih]-)*defUnpack
:defines the default unpack code for this object type.

;dev-([cdih]-)*defRevRegs
:defines that the order of registers for objects that span several registers will be reversed before
:further interpretation / unpacking of the raw register string

;dev-([cdih]-)*defBswapRegs
:per device default for swapping the bytes in Registers (see obj-bswapRegs above)

;dev-([cdih]-)*defDecode
:defines a default for decoding the strings read from a different character set e.g. cp850

;dev-([cdih]-)*defEncode
:defines a default for encoding the strings read (or after decoding from a different character set) e.g. utf8

;dev-([cdih]-)*defPoll
:if set to 1 then all objects of this type will be included in the cyclic update by default.

;dev-([cdih]-)*defShowGet
:if set to 1 then all objects of this type will have a visible get by default.

;dev-timing-timeout
:timeout for the device (defaults to 2 seconds)

;dev-timing-sendDelay
:delay to enforce between sending two requests to the device. Default ist 0.1 seconds.

;dev-timing-commDelay
:delay between the last read and a next request. Default ist 0.1 seconds.

;dev-([cdih]-)*allowShortResponses
:if set to 1 the module will accept a response with valid checksum but data lengh < lengh in header

;dev-timing-timeout
:timeout for the device (defaults to 2 seconds)

;dev-timing-sendDelay
:delay to enforce between sending two requests to the device. Default ist 0.1 seconds.

;dev-timing-commDelay
:delay between the last read and a next request. Default ist 0.1 seconds.

;nextOpenDelay
:delay for Modbus-TCP connections.
:This defines how long the module should wait after a failed TCP connection attempt before the next reconnection attempt.
:This defaults to 60 seconds.

;openTimeout
:timeout to be used when opening a Modbus TCP connection (defaults to 3)

;timeoutLogLevel
:log level that is used when logging a timeout. Defaults to 3.

;silentReconnect
:if set to 1, then it will set the loglevel for "disconnected" and "reappeared" messages to 4 instead of 3

;maxTimeoutsToReconnect
:this attribute is only valid for TCP connected devices.
:In such cases a disconnected device might stay undetected and lead to timeouts until the TCP connection is reopened.
:This attribute specifies after how many timeouts an automatic reconnect is tried.

;dev-h-brokenFC3
:workaround for some broken Modbus function code 3 implementations

;disable
:stop communication with the device while this attribute is set to 1. For Modbus over TCP this also closes the TCP connection.

== Links ==
* [http://www.Modbus.org Modbus.org]
* About Modbus ([http://en.wikipedia.org/wiki/Modbus English] / [http://de.wikipedia.org/wiki/Modbus German])
* Perl [http://perldoc.perl.org/functions/pack.html unpack codes]

[[Kategorie:IP Components]]

ModbusAttr

2020-01-05T15:07:31Z

ZDX: /* Get-Commands */

{{Infobox Modul
|ModPurpose=Extract information from devices with a Modbus interface or send information to such devices
|ModType=d
|ModCmdRef=ModbusAttr
|ModForumArea=Sonstiges
|ModFTopic=25315
|ModTechName=98_ModbusAttr.pm
|ModOwner=StefanStrobel ({{Link2FU|3960|Forum}} / [[Benutzer:StefanStrobel|Wiki]])
}}

[[ModbusAttr]] uses the low level Modbus module 98_[[Modbus]].pm to provide a generic Modbus module (as master, slave, relay or passive listener)
that can be configured by attributes similar to the way HTTPMOD works for devices with a web interface.

ModbusAttr can be used as a Modbus master that queries data from other devices over a serial RS232 / RS485 or TCP connection,
it can be used as a Modbus slave that can make readings of Fhem devices available via Modbus to external Modbus masters,
it can act as a Modbus relay that receives requests over one connection and forwards them over another connection (e.g. from Modbus TCP to serial Modbus RTU)
or it can passively listen to other devices that communicate over a serial RS485 connection and extract readings from the objects it sees.
The supported protocols are Modbus RTU, Modbus ASCII or Modbus TCP.

There are several attributes that modify the way data objects are converted before they are stored in readings or sent to a device. Data can be modified by a perl expression defined in an atribute, formatted with a format string defined in another attribute or mapped to a table defined in an attribute.

Readings can directly correspond to one data object or they can span several objects. A float value for example might be stored in two input or holding registers in the Modbus device. By specifying attributes that define the length of a reading in objects and by specifying the unpack code to get from a raw string to perl variables, all these cases can be described by attributes and no perl coding is necessary.

== Availability ==
The module has been checked in.

== Prerequisites ==
This module uses the [[Modbus|Modbus base module 98_Modbus.pm]] which uses the DevIO module

== Define as Modbus master ==

<pre>
define <iodevice> Modbus /dev/device@baudrate,bits,parity,stop
define <name> ModbusAttr <Id> <Interval> <RTU|ASCII>
</pre>
or
<pre>
define <name> ModbusAttr <Id> <Interval> <Address:Port> <RTU|ASCII|TCP>
</pre>

In the first case the module connects to the external Modbus device with Modbus Id <Id> through a serial modbus device (RS232 or RS485).

In the second case it connects directly through Modbus TCP or Modbus RTU or ASCII over TCP.

If <Interval> is not 0 then the module actively requests data from that device every <Interval> seconds.

The objects that the module should request and the readings it should create from these objects have to be defined with attributes (see below).
These attributes will define a mapping from so called "coils", "digital inputs", "input registers" or "holding registers" of the external device to readings inside Fhem together with the data type and format of the values.
Interval can be 0 in which case the Module only requests data when it is triggered with a Fhem get-Command.
With this mode a Fhem installation can for example query sensor data from a heating system, energy meter or solar power installation if these systems offer a Modbus interface.

Examples:

<pre>
define ModbusLine Modbus /dev/ttyUSB1@9600
define WP ModbusAttr 1 60
</pre>
Define WP as a Modbus master that communicates through the Modbus serial interface device named ModbusLine. The protocol defaults to Modbus RTU

<pre>
define ModbusLine Modbus /dev/ttyUSB1@9600
define WP ModbusAttr 20 0 ASCII
</pre>
Define WP as a Modbus master that communicates through the Modbus serial interface device named ModbusLine with Modbus ASCII.
Use Modbus Id 20 and don't query the device in a defined interval. Instead individual SET / GET options have to be used for communication.

<pre>
define WP ModbusAttr 5 60 192.168.1.122:502 TCP
</pre>
to talk Modbus TCP to a device with IP-Address 192.168.1.122 and the reserved port for Modbus TCP 502
Note that for Modbus over a TCP connection you don't need a basic Modbus device for the interface like ModbusLine above.

<pre>
define WP ModbusAttr 3 60 192.168.1.122:8000 RTU
</pre>
to talk Modbus RTU over TCP and use the port number 8000

== Define as Modbus slave ==

<pre>
define <name> ModbusAttr <Id> slave
</pre>
or
<pre>
define <name> ModbusAttr <Id> slave <Address:Port> <RTU|ASCII|TCP>
</pre>

The module waits for connections from other Modbus masters. It will respond to their requests if the requests contain the given Modbus <Id>
To provide data with Modbus to external Modbus masters a mapping needs to be defined using attributes.
These attributes will define a mapping from Readings inside Fhem to so called "coils", "digital inputs", "input registers" or "holding registers" and their Modbus object address together with the data type and format of the values.
With this mode a Fhem installation can for example supply data to a PLC that actively reads data from Fhem or writes data to Fhem readings.

Examples:

<pre>
define MRS485 Modbus /dev/ttyUSB2@9600,8,E,1
define Data4PLC ModbusAttr 1 slave
</pre>
Define Data4PLC as a Modbus slave that communicates through the Modbus serial interface device named MRS485 to listen for Modbus requests with Id 1. The protocol defaults to Modbus RTU

<pre>
define MRS485 Modbus /dev/ttyUSB2@9600,8,E,1
define Data4PLC ModbusAttr 20 slave ASCII
</pre>
to listen for Modbus requests with Id 20 with Modbus ASCII.

<pre>
define Data4PLC ModbusAttr 5 slave 192.168.1.2:502 TCP
</pre>
to start listening to TCP port 502 on the local address 192.168.1.2. Modbus TCP will be used as protocol and Requests with Modbus Id 5 will be answered.

Please be aware that opening a port number smaller than 1024 needs root permissions on Unix devices. So it is probably better to use a non standard port number above 1024 instead.

<pre>
define Data4PLC ModbusAttr 3 slave 192.168.1.2:8000 RTU
</pre>
to listen to the local port 8000 and talk Modbus RTU over TCP

== Define as Modbus passive listener ==

<pre>
define <name> ModbusAttr <Id> passive <RTU|ASCII|TCP>
</pre>

The module listens on a serial (RS485) connection for modbus communication with the given Modbus <Id> and extracts readings. It does not send requests by itself but waits for another master to communicate with a slave. So only objects that the other master requests can be seen by Fhem in this configuration.
The objects that the module recognizes and the readings that it should create from these objects have to be defined with attributes (see below) in the same way as for a Modbus master.
These attributes will define a mapping from so called "coils", "digital inputs", "input registers" or "holding registers" of the external device to readings inside Fhem together with the data type and format of the values.
With this mode a Fhem installation can for example Listen to the communication between an energy counter as slave and a solar control system as master if they use Modbus RTU over RS485. Since only one Master is allowed when using Modbus over serial lines, Fhem can not be master itself. As a passive listener it can however see when the master queries e.g. the current power consumption and then also see the reply from the energy meter and store the value in a Fhem reading.

Examples:

<pre>
define MB-485 Modbus /dev/ttyUSB2
define WP ModbusAttr 1 passive
</pre>
to passively listen for Modbus requests and replies with Id 1 over a serial interface managed by an already defined basic modbus device named MB-485. The protocol defaults to Modbus RTU

<pre>
define MB-485 Modbus /dev/ttyUSB2
define WP ModbusAttr 20 passive ASCII
</pre>
to passivel listen for Modbus requests / replies with Id 20 and Modbus ASCII.

== Define as Modbus relay ==

<pre>
define <name> ModbusAttr <Id> relay to <FhemMasterDevice>
</pre>
or
<pre>
define <name> ModbusAttr <Id> relay <Address:Port> <RTU|ASCII|TCP> to <FhemMasterDevice>
</pre>

The module waits for connections from other Modbus masters. It will forward requests if they match the given Modbus <Id> to an already defined Modbus Master device inside Fhem which will send them to its defined slave, take the reply and the pass it back to the original Master.
With this mode a Fhem installation can for example be used in front of a device that only speaks Modbus RTU over RS485 to make it available via Modbus TCP over the local network.

Examples:

<pre>
define MB-485 Modbus /dev/ttyUSB2
define Heating ModbusAttr 22 0
define Relay ModbusAttr 33 relay 192.168.1.2:1502 TCP to Heating
</pre>
Defines MB-485 as a base device for the RS-485 communication with a heating system,
defines Heating as a Modbus Master to communicate with the Heating and its Modbus ID 22,
and then defines the relay which listens to the local IP address 192.168.1.2, TCP port 1502, Modbus Id 33 and protocol Modbus-TCP.
Requests coming in through Modbus TCP and port 1502 are then translated to Modbus RTU and forwarded via RS-485 to the heating system with Modbus Id 22.

or (unlikely)
<pre>
define MB-232 Modbus /dev/ttyUSB2@19200
define Solar ModbusAttr 7 0 192.168.1.122:502 RTU
define PLC2NetRelay ModbusAttr 1 ASCII relay to Solar
</pre>
Defines MB-232 as a base device for the RS-232 communication with a PLC as Modbus master,
defines Solar as a Modbus Master to communicate with Modbus TCP to a Solar power system at IP Adrress 192.168.1.122 and its Modbus ID 7,
and then defines the PLC2NetRelay as a relay which listens to Modbus-ASCII requests over the serial RS-232 link from a PLC to Modbus ID 1.
Requests to Modbus Id 1 coming in through the serial link are then translated to Modbus TCP and forwarded over the network to the solar power system with Modbus Id 7.

== Configuration of the module as master or passive listener ==

Data objects (holding registers, input registers, coils or discrete inputs) are defined using attributes.
If Fhem is Modbus master or passive listener, the attributes assign data objects of external devices (heating systems, power meters, PLCs or other) with their register addresses to readings inside fhem and control how these readings are calculated from the raw values and how they are formatted.
Please be aware that Modbus does not define common data types so the representation of a value can be very different from device to device. One device might make a temperature value avaliable as a floating point value that is stored in two holding resgisters, another device might store the temperature multiplied with 10 as an signed integer in one register. Even the order of bytes can vary.
Therefore it is typically necessary to specify the data representation as a Perl unpack code.
A Modbus master can also write values to Objects in the device and attributes define how this is done.

Example for a Modbus master or passive configuration:
<pre>
define PWP ModbusAttr 5 30
attr PWP obj-h256-reading Temp_Wasser_ein
attr PWP obj-h256-expr $val/10

attr PWP obj-h258-reading Temp_Wasser_Aus
attr PWP obj-h258-expr $val/10

attr PWP obj-h262-reading Temp_Luft
attr PWP obj-h262-expr $val / 10

attr PWP obj-h770-reading Temp_Soll
attr PWP obj-h770-expr $val / 10
attr PWP obj-h770-set 1
attr PWP obj-h770-setexpr $val * 10
attr PWP obj-h770-max 32
attr PWP obj-h770-min 10
attr PWP obj-h770-hint 8,10,20,25,28,29,30,30.5,31,31.5,32

attr PWP dev-h-combine 5
attr PWP dev-h-defPoll 1
attr PWP dev-h-defUnpack n

attr PWP room Pool-WP
attr PWP stateFormat {sprintf("%.1f Grad", ReadingsVal($name,"Temp_Wasser_Ein",0))}
attr PWP webCmd Temp_Soll
</pre>

Attributes to define data objects start with obj- followed by a code that identifies the type and address
of the data object.

Modbus devices offer the following types of data objects:

;holding registers (16 bit objects that can be read and written)
;input registers (16 bit objects that can only be read)
;coils (single bit objects that can be read and written)
;discrete inputs (single bit objects that can only be read)

The module uses the first character of these data object types to define attributes.
Thus h770 refers to a holding register with the decimal address 770 and c120 refers to a coil with address 120.
The address has to be specified as pure decimal number. The address counting starts at address 0

Please note that the documentation for devices sometimes uses different numbering. They might start counting with one instead of zero so if a voltage value is stored in input register number 107 according to the documentation of the device, it might technically mean register number 106 (in the Modbus protocol specification addresses start with 0).
Also some vendors use hexadecimal descriptions of their register addresses. So input register 107 might be noted as hex and means 263 or even 262 as decimal address.

<pre>
attr PWP obj-h258-reading Temp_Wasser_Aus
</pre>
defines a reading with the name Temp_Wasser_Aus that is read from the Modbus holding register at address 258.
With the attribute ending on <code>-expr</code> you can define a perl expression to do some conversion or calculation on the raw value read from the device.
In the above example the raw value has to be devided by 10 to get the real value. If the raw value is also the final value then no <code>-expr</code> attribute is necessary.

An object attribute ending on <code>-set</code> creates a fhem set option.
In the above example the reading Temp_Soll can be changed to 12 degrees by the user with the fhem command <code>set PWP Temp_Soll 12</code>
The object attributes ending on <code>-min</code> and <code>-max</code> define min and max values for input validation
and the attribute ending on <code>-hint</code> will tell fhem to create a selection list so the user can graphically select the defined values.

To define general properties of the device you can specify attributes starting with <code>dev-</code>.
E.g. with <code>dev-timing-timeout</code> you can specify the timeout when waiting for a response from the device.
With <code>dev-h-</code> you can specify several default values or general settings for all holding registers
like the function code to be used when reading or writing holding registers.
These attributes are optional and the module will use defaults that work in most cases.
<code>dev-h-combine 5</code> for example allows the module to combine read requests to objects having an address that differs 5 or less into one read request.
Without setting this attribute the module will start individual read requests for each object.
Typically the documentation for the modbus interface of a given device states the maximum number of objects that can be read in one function code 3 request.
<code>dev-h-defUnpack n</code> means that the values in this example that the values are stored as unsigned short (16-bit) in "network" (big-endian) order. This is only one possibility of many. An integer value might be signed instead of unsigned or it might use different byte ordering (e.g. unpack codes v or s).

== Handling Data Types ==

The Modbus protocol does not define data types. If the documentation of a device states that for example the current temperature is stored in holding register 102 this leaves room for many interpretations. Not only can the address 102 mean different things (actually decimal 102 or rather 101 if the vendor starts counting at 1 instead of 0 or even 257 or 258 if the vendor used hexadecimal addresses in his documentation ) also the data representation can be many different things. As in every programming language, there are many ways to represent numbers. They can be stored signed or unsigned, they can be integers or floating point numbers, the byte-order can be "big endian" or "small endian", the value can be stored in one holding register or in two holding registers (floating point numbers typically take four bytes which means two holding registers).
The Modbus module allows flexible configuration of data representations be assigning a Perl unpack-code, a length, a Perl Expression, and the register ordering. The following example illustrates how this can be done:
<pre>
attr PWP obj-h338-reading Pressure
attr PWP obj-h338-len 2
attr PWP obj-h338-unpack f>
attr PWP obj-h338-revRegs 1
attr PWP obj-h338-format %.2f
</pre>
In This example a floating point value for the reading "Pressure" is read from the holding registers starting at address 338.
The value occupies 32 Bits and is therefore stored in two registers. The Perl pack code to use is f> which means a native single precision float in big endian format (byte order). With revRegs the module is instructed to reverse the order of the registers directly after reading. The format specification then defines how the value is formatted into a reading - in this case with two digits after the comma. See http://perldoc.perl.org/functions/pack.html for Perl pack / unpack codes and http://perldoc.perl.org/functions/sprintf.html for format specifications.

If you need to read / write many objects for a device, defining all these parameters each time is not elegant. The Modbus module therefore offers twi ways to simplify this task:
You can define defaults for every type of object or you can define your own data types once and then refer to them.
This exampe shows how defaults can be specified for holding registers and input registers:
<pre>
attr PWP dev-h-defUnpack f>
attr PWP dev-h-defLen 2
attr PWP dev-h-defRevRegs 1
attr PWP dev-h-defFormat %.2f

attr PWP dev-i-defUnpack n
attr PWP dev-i-defLen 1
</pre>

The next example shows how you can define your own data types and then apply them to objects:
<pre>
attr WP dev-type-VT_R4-format %.1f
attr WP dev-type-VT_R4-len 2
attr WP dev-type-VT_R4-revRegs 1
attr WP dev-type-VT_R4-unpack f>

attr WP obj-h1234-reading Temp_In
attr WP obj-h1234-type VT_R4
attr WP obj-h1236-reading Temp_Out
attr WP obj-h1236-type VT_R4
</pre>
This example defines a data type with the name VT_R4 which uses an unpack code of f>, length 2 and reversed register ordering. It then assigns this Type to the objects Temp_In and Temp_Out.

== Configuration of the module as Modbus slave ==

Data objects that the module offers to external Modbus masters (holding registers, input registers, coils or discrete inputs) are defined using attributes.
If Fhem is Modbus slave, the attributes assign readings of Fhem devices to Modbus objects with their addresses and control how these objects are calculated from the reading values that exist in Fhem.
It is also possible to allow an external Modbus master to send write function codes and change the value of readings inside Fhem.

Example for a Modbus slave configuration:
<pre>
define MRS485 Modbus /dev/ttyUSB2@9600,8,E,1
define Data4PLC ModbusAttr 1 slave
attr Data4PLC IODev MRS485

attr Data4PLC obj-h256-reading THSensTerrasse:temperature
attr Data4PLC obj-h256-unpack f
attr Data4PLC obj-h256-len 2

attr Data4PLC obj-h258-reading THSensTerrasse:humidity
attr Data4PLC obj-h258-unpack f
attr Data4PLC obj-h258-len 2

attr Data4PLC obj-h260-reading myDummy:limit
attr Data4PLC obj-h260-unpack n
attr Data4PLC obj-h260-len 1
attr Data4PLC obj-h260-allowWrite 1
</pre>

In this example Fhem allows an external Modbus master to read the temperature of a Fhem device named THSensTerrasse through holding register 256 and the humidity of that Fhem device through holding register 258. Both are encoded as floting point values that span two registers.
The master can also read but also write the reading named limit of the device myDummy.

== Set-Commands ==
can be defined for holding registers and coils by using attributes.

Every object for which an attribute like <code>obj-xy-set</code> is set to 1 will create a valid set option.

Additionally the attribute <code>enableControlSet</code> enables the set options <code>interval</code>, <code>stop</code>, <code>start</code>, <code>reread</code> as well as <code>scanModbusObjects</code>, <code>scanStop</code> and <code>scanModbusIds</code> (for devices connected with RTU / ASCII over a serial line).

;<code>interval <Interval></code>
:modifies the interval that was set during define.

;<code>stop</code>
:stops the interval timer that is used to automatically poll objects through Modbus.

;<code>start</code>
:starts the interval timer that is used to automatically poll objects through Modbus.
:If an interval is specified during the define command then the interval timer is started automatically.
:However if you stop it with the command <code>set <mydevice> stop</code>
:then you can start it again with <code>set <mydevice> start</code>.

;<code>reread</code>
:causes a read of all objects that are set to be polled in the defined interval. The interval timer is not modified.

;<code>scanModbusObjects <startObj> - <endObj> <reqLen></code>
:scans the device objects and automatically creates attributes for each reply it gets.
:This might be useful for exploring devices without proper documentation.
:The following example starts a scan and queries the holding registers with addresses between 100 and 120.
:<code>set MyModbusAttrDevice scanModbusObjects h100-120</code> 
:For each reply it gets, the module creates a reading like
:<code>scan-h100 hex=0021, string=.!, s=8448, s>=33, S=8448, S>=33</code> 
:the representation of the result as hex is 0021 and
:the ASCII representation is .!. s, s>, S and S> are different representations with their Perl pack-code.

;<code>scanModbusIds <startId> - <endId> <knownObj></code>
:scans for Modbus Ids on an RS485 Bus. The following set command for example starts a scan: 
:<code>set Device scanModbusId 1-7 h770</code> 
:since many Modbus devices don't reply at all if an object is requested that does not exist,
:scanModbusId needs the adress of an object that is known to exist.
:If a device with Id 5 replies to a read request for holding register 770, a reading like the following will be created:
:<code>scanId-5-Response-h770 hex=0064, string=.d, s=25600, s>=100, S=25600, S>=100</code>
;<code>scanStop</code>
:stops any running scans.
;saveAsModule <name>
:experimental: saves the definitions of obj- and dev- attributes in a new fhem module file as /tmp/98_ModbusGen<name>.pm.
:if this file is copied into the fhem module subdirectory (e.g. /opt/fhem/FHEM) and fhem is restarted then instead of defining a device
:as ModbusAttr with all the attributes to define objects, you can just define a device of the new type ModbusGen<name> and all the
:objects will be there by default. However all definitions can still be changed / overriden with the attribues defined in ModbusAttr if needed.

== Get-Commands ==

Every reading can be manually requested by a Get.
Internally a Get command triggers the corresponding Modbus request to the device and the module then interprets the data and sets the right Fhem readings. To avoid huge option lists in FHEMWEB, the objects visible as Get in FHEMWEB can be defined by setting an attribute <code>obj-xy-showGet</code> to 1.

== All Attributes ==

;readingFnAttributes
:the usual Fhem attributes for all devices

;alignTime
:Aligns each periodic read request for the defined interval to this base time.
:This is typcally something like 00:00 (see the Fhem at command)

;enableControlSet
:enables the built in set commands like interval, stop, start and reread (see above)

the following list of attributes can be applied to any data object by specifying the objects type and address in the variable part.
For many attributes you can also specify default values per object type (see dev- attributes later) or you can specify an object attribute without type and address (e.g. obj-len) which then applies as default for all objects:

;obj-[cdih][1-9][0-9]*-reading
:define the name of a reading that corresponds to the Modbus data object of type c,d,i or h and a decimal address (e.g. obj-h225-reading).

;obj-[cdih][1-9][0-9]*-name
:defines an optional internal name of this data object (this has no meaning for fhem and serves mainly documentation purposes.

;obj-[cdih][1-9][0-9]*-set
:if set to 1 then this data object can be changed (works only for holding registers and coils since discrete inputs and input registers can not be modified by definition.

;obj-[cdih][1-9][0-9]*-min
:defines a lower limit to the value that can be written to this data object. This ist just used for input validation.

;obj-[cdih][1-9][0-9]*-max
:defines an upper limit to the value that can be written to this data object. This ist just used for input validation.

;obj-[cdih][1-9][0-9]*-hint
:this is used for set options and tells fhemweb what selection to display for the set option (list or slider etc.)

;obj-[cdih][1-9][0-9]*-expr
:defines a perl expression that converts the raw value read from the device.

;obj-[cdih][1-9][0-9]*-ignoreExpr
:defines a perl expression that returns 1 if a value should be ignored and the existing reading should not be modified

;obj-[cdih][1-9][0-9]*-map
:defines a map to convert values read from the device to more convenient values when the raw value is read from the device or back when the value to write has to be converted from the user value to a raw value that can be written. Example: 0:mittig, 1:oberhalb, 2:unterhalb

;obj-[cdih][1-9][0-9]*-setexpr
:defines a perl expression that converts the user specified value in a set to a raw value that can be sent to the device. This is typically the inversion of -expr above.

;obj-[cdih][1-9][0-9]*-format
:defines a format string to format the value read e.g. %.1f

;obj-[cdih][1-9][0-9]*-len
:defines the length of the data object in registers. It defaults to 1. Some devices store 32 bit floating point values in two registers. In this case you can set this attribute to two.

;obj-[cdih][1-9][0-9]*-unpack
:defines the unpack code to convert the raw data string read from the device to a reading. For an unsigned integer in big endian format this would be "n", for a signed 16 bit integer in big endian format this would be "s>" and for a 32 bit big endian float value this would be "f>". (see the perl documentation of the pack function).

;obj-[cdih][1-9][0-9]*-revRegs
:this is only applicable to objects that span several input registers or holding registers.
:when they are read then the order of the registers will be reversed before
:further interpretation / unpacking of the raw register string.
:The same happens before the object is written with a set command.

;obj-[cdih][1-9][0-9]*-bswapRegs
:this is applicable to objects that span several input or holding registers.
:After the registers have been read and before they are writtem,
:all 16-bit values are treated big-endian and are reversed to little-endian by swapping the two 8 bit bytes.
:This functionality is most likely used for reading (ASCII) strings from the device
:that are stored as big-endian 16-bit values.
:example: original reading is "324d3130203a57577361657320722020". After applying bswapRegs,
:the value will be "4d3230313a2057576173736572202020" which will result in the ASCII string
:"M201: WWasser ".
:Should be used with "(a*)" as -unpack value.

;obj-[cdih][1-9][0-9]*-decode
:defines an encoding to be used in a call to the perl function decode to convert the raw data string
:read from the device to a reading.
:This can be used if the device delivers strings in an encoding like cp850 instead of utf8.

;obj-[cdih][1-9][0-9]*-encode
:defines an encoding to be used in a call to the perl function encode to convert the raw data string
:read from the device to a reading.
:This can be used if the device delivers strings in an encoding like cp850 and after decoding it you want to reencode it to e.g. utf8.

;obj-[cdih][1-9][0-9]*-showget
:every reading can also be requested by a get command. However these get commands are not automatically offered in fhemweb. By specifying this attribute, the get will be visible in fhemweb.

;obj-[cdih][1-9][0-9]*-poll
:if set to 1 then this obeject is included in the cyclic update request as specified in the define command. If not set, then the object can manually be requested with a get command, but it is not automatically updated each interval. Note that this setting can also be specified as default for all objects with the dev- atributes described later.

;obj-[cdih][1-9][0-9]*-polldelay
:this attribute allows to poll objects at a lower rate than the interval specified in the define command. you can either specify a time in seconds or number prefixed by "x" which means a multiple of the interval of the define command. if you specify a normal numer then it is interpreted as minimal time between the last read and another automatic read. Please note that this does not create an individual interval timer. Instead the normal interval timer defined by the interval of the define command will check if this reading is due or not yet. So the effective interval will always be a multiple of the interval of the define.

;dev-([cdih]-)*read
:specifies the function code to use for reading this type of object. The default is 3 for holding registers, 1 for coils, 2 for discrete inputs and 4 for input registers.

;dev-([cdih]-)*write
:specifies the function code to use for writing this type of object. The default is 6 for holding registers and 5 for coils. Discrete inputs and input registers can not be written by definition.

;dev-([cdih]-)*combine
:defines how many adjacent objects can be read in one request. If not specified, the default is 1

;dev-([cdih]-)*defLen
:defines the default length for this object type. If not specified, the default is 1

;dev-([cdih]-)*defFormat
:defines a default format string to use for this object type in a sprintf function on the values read from the device.

;dev-([cdih]-)*defExpr
:defines a default Perl expression to use for this object type to convert raw values read.

;dev-([cdih]-)*defIgnoreExpr
:defines a default Perl expression to decide when values should be ignored.

;dev-([cdih]-)*defUnpack
:defines the default unpack code for this object type.

;dev-([cdih]-)*defRevRegs
:defines that the order of registers for objects that span several registers will be reversed before
:further interpretation / unpacking of the raw register string

;dev-([cdih]-)*defBswapRegs
:per device default for swapping the bytes in Registers (see obj-bswapRegs above)

;dev-([cdih]-)*defDecode
:defines a default for decoding the strings read from a different character set e.g. cp850

;dev-([cdih]-)*defEncode
:defines a default for encoding the strings read (or after decoding from a different character set) e.g. utf8

;dev-([cdih]-)*defPoll
:if set to 1 then all objects of this type will be included in the cyclic update by default.

;dev-([cdih]-)*defShowGet
:if set to 1 then all objects of this type will have a visible get by default.

;dev-timing-timeout
:timeout for the device (defaults to 2 seconds)

;dev-timing-sendDelay
:delay to enforce between sending two requests to the device. Default ist 0.1 seconds.

;dev-timing-commDelay
:delay between the last read and a next request. Default ist 0.1 seconds.

;dev-([cdih]-)*allowShortResponses
:if set to 1 the module will accept a response with valid checksum but data lengh < lengh in header

;dev-timing-timeout
:timeout for the device (defaults to 2 seconds)

;dev-timing-sendDelay
:delay to enforce between sending two requests to the device. Default ist 0.1 seconds.

;dev-timing-commDelay
:delay between the last read and a next request. Default ist 0.1 seconds.

;nextOpenDelay
:delay for Modbus-TCP connections.
:This defines how long the module should wait after a failed TCP connection attempt before the next reconnection attempt.
:This defaults to 60 seconds.

;openTimeout
:timeout to be used when opening a Modbus TCP connection (defaults to 3)

;timeoutLogLevel
:log level that is used when logging a timeout. Defaults to 3.

;silentReconnect
:if set to 1, then it will set the loglevel for "disconnected" and "reappeared" messages to 4 instead of 3

;maxTimeoutsToReconnect
:this attribute is only valid for TCP connected devices.
:In such cases a disconnected device might stay undetected and lead to timeouts until the TCP connection is reopened.
:This attribute specifies after how many timeouts an automatic reconnect is tried.

;dev-h-brokenFC3
:workaround for some broken Modbus function code 3 implementations

;disable
:stop communication with the device while this attribute is set to 1. For Modbus over TCP this also closes the TCP connection.

== Links ==
* [http://www.Modbus.org Modbus.org]
* About Modbus ([http://en.wikipedia.org/wiki/Modbus English] / [http://de.wikipedia.org/wiki/Modbus German])
* Perl [http://perldoc.perl.org/functions/pack.html unpack codes]

[[Kategorie:IP Components]]

BEOK

2019-04-30T21:01:45Z

ZDX: lock Beschreibung hinzugefügt

{{Infobox Modul
|ModPurpose=WiFi Raum-Thermostate für FHEM
|ModType=d
|ModCmdRef=BEOK
|ModForumArea=Heizungssteuerung/Raumklima
|ModTechName=38_BEOK.pm
|ModOwner=Wzut ({{Link2FU|1172|Forum}} / [[Benutzer Diskussion:plin/Wzut|Wiki]])}}

Das Modul '''BEOK''' implementiert die Steuerung von FHEM zu BEOK / Floureon / Hysen WiFi Raum-Thermostaten.

== Voraussetzungen ==
=== FHEM-Server ===

Da das Modul AES-Verschlüsselung benötigt, müssen ggf. noch zusätzliche Perl Module installiert werden. 

Bsp. für Debian/Raspian : 
<code>sudo apt-get install libcrypt-cbc-perl</code>
<code>sudo apt-get install libcrypt-rijndael-perl</code>
<code>sudo apt-get install libssl-dev</code>
<code>sudo cpan Crypt/OpenSSL/AES.pm</code>

=== Hardware ===
Bezugsquellen : 
[https://www.amazon.de/Fussbodenheizung-Touchscreen-Intelligente-Programmierbare-Raumthermostat/dp/B07B8TKG5Y/ Amazon] Chunyang weiss Tasten 28€ 
 
[https://de.aliexpress.com/item/16A-AC-220-V-WIFI-Heizung-Thermostat-Wasser-Elektrische-Heizung-System-WIFI-Thermostat-APP-Steuert-f/32889325428.html Ali] KETOTEK weiss Tasten ca 25€ 
 
[https://www.amazon.de/FLOUREON-programmierbar-Fussbodenheizung-Heizungsthermostat-Heizungsregelung/dp/B077G6JKCX/ref=sr_1_2?s=diy&ie=UTF8&qid=1547653340&sr=1-2&keywords=floureon+wifi+raumthermostat Amazon] Floureon schwarz Touch 40 € 
 
[https://de.aliexpress.com/item/Floureon-Smart-Wi-Fi-Programmable-Thermostat-Digital-Touch-Screen-Room-Temperature-Controller-NTC-Underfloor-Heating-Thermostat/32826733099.html Ali] Floureon schwarz Touch 31 €
 
[https://www.amazon.de/BEOK-tds21wifi-ep-Raumthermostat-programmierbar-Fu%C3%9Fbodenheizung/dp/B075WPWGH5/ Amazon]
BEOK TDS21 weiß Touch ca 40€ – z.Z. bei Ali nicht lieferbar 

== Installation ==
=== Erste Schritte ===
Spätestens nach einem 'update all' sollte das Modul '''38_BEOK.pm''' verfügbar sein.

Nun ist ein Device in FHEM anzulegen:

:<code>define <name> BEOK <ip> [mac]</code>

Zum Beispiel
<code>define Thermo BEOK 192.168.1.100</code>
<code>define Thermo BEOK 192.168.1.100 de:ad:be:ef:01:02</code>

== Anwendung ==
=== Attribute ===

* '''interval'''
: Poll Intevall in Sekunden, 0 = kein Polling , default 60
* '''timesync'''
: Uhrzeit und Wochentag automatisch mit FHEM synchronisieren, default 1 (an)
* '''timeout'''
: Timeout in Sekunden für die Netzwerk Kommunikation, default 5
* '''language'''
: de oder DE für deutsche Bezeichnungen, Raum statt Room , usw.
* '''model'''
: nur für die FHEM Modul Statistik unter [https://fhem.de/stats/statistics.html https://fhem.de/stats/statistics.html]

=== Set ===

Das Modul kennt derzeit folgende Commands

* set <name> '''desired-temp <5 - 99>'''
: Gewünschte Zieltemperatur

* set <name> '''mode <auto|manual>'''
: Modus auf automatisch oder manuell setzen

* set <name> '''loop <12345.67 123456.7 1234567>'''
: 12345.67 Montag - Freitag Werktag, Samstag & Sonntag sind Wochenende
: 123456.7 Montag - Samstag Werktag, nur Sonntag ist Wochendende
: 1234567 jeder Tag (inklusive Samstag & Sonntag) ist ein Werktag, kein Wochenende

* set <name> '''sensor <external|internal|both>'''
: both = internal control temperature, external limit temperature

* set <name> '''time'''
: synchronisiert Uhrzeit und Wochentag mit FHEM

* set <name> '''lock <on off>'''
: sperrt die Tasten am Gerät (außer ein/aus), Bedienung nur via W-LAN möglich

* set <name> '''power-on-memory <on off>'''
: tbd

* set <name> '''fre <open|close>'''
: Frostschutz Funktion

* set <name> '''room-temp-adj <-5 - +5>'''
: Korrekturwert (Offset) Raumtemperatur

* set <name> '''osv <5 - 99>'''
: Maximum Temperatur für externen Sensor

* set <name> '''svh <5 - 99>'''
: Raumtemperatur Maximum

* set <name> '''svl <5 - 99>'''
: Raumtemperatur Minimum

* set <name> '''dif <1 - 9>'''
: difference of limit temperature value of external sensor

* set <name> '''day-profil[1-6]-temp <5 - 99>'''
: Werktagprofil Temperatur

* set <name> '''day-profil[1-6]-time <00:00 - 23:59>'''
: Werktagprofil Zeit

* set <name> '''we-profile[7-8]-temp <5 - 99>'''
: Wochenendprofil Temperatu

* set <name> '''we-profile[7-8]-time <00:00 - 23:59>'''
: Wochenendprofil Zeit

* set <name> '''weekprofile'''
: Setzt alle Wochentag Schaltzeiten und Temperaturen mit Werten aus einem Profil des Moduls weekprofile.
: Syntax : set weekprofile <weekprofile_device:profil_name[:Wochentag]>
: siehe auch Erklärung im Forum :{{Link2Forum|Topic=80703|Message=901303}}

== Anwendungsbeispiele ==

folgen noch

== Bekannte Probleme / Fehlersuche ==

folgen noch

== Links ==
* Erläuterung im Forum: {{Link2Forum|Topic=80703|Message=901303}}
* FHEM Modul Statistik unter [https://fhem.de/stats/statistics.html https://fhem.de/stats/statistics.html]

[[Kategorie:Heizungssteuerung]]

Waterkotte heat pump with Resümat CD4

2019-04-21T17:41:37Z

ZDX: Hinweis zu anderer Version verbessert

{{Infobox Modul
|ModPurpose=Control / Extract information from Waterkotte Heat pumps with Resümat CD4 controller
|ModType=contrib
|ModCmdRef=WKRCD4
|ModForumArea=Sonstiges
|ModFTopic=17658
|ModTechName=98_WKRCD4.pm
|ModOwner=StefanStrobel ({{Link2FU|3960|Forum}} / [[Benutzer:StefanStrobel|Wiki]])
}}
WKRCD4 allows to control / communicate with older heat pumps from Waterkotte that have a control unit called Resümat CD4 with an RS232 serial interface. Newer heat pumps from Waterkotte typically have a modbus interface that can be controlled with module [[ModbusAttr]].
 
CD4 control units with software version 7000, 8000 or 8011 can be controlled with [https://forum.fhem.de/index.php/topic,83006.msg886622.html#msg886622 another version] of the WKRCD4 module.

== Availability ==
The module has been checked in to the contrib area.

== Prerequisites ==
This module requires Device::SerialPort or Win32::SerialPort module.

== Define ==
<pre>
define <name> WKRCD4 <devicename@speed> <Interval>
</pre>
The module connects to the heat pump through a serial interface and actively requests data from the heat pump every <Interval> seconds

=== Example:===

<pre>
define WP WKRCD4 /dev/dualser0@9600 60
attr WP stateFormat Status
attr WP event-min-interval .*:3600
attr WP event-on-change-reading .*
</pre>

== Configuration of the module ==
Apart from the serial interface and the interval there is nothing that needs to be defined.

== Get-Commands ==
There are only two parameters for which an explicit GET has been implemented. Most values are just readings that are automatically requested:
<pre>
Hzg-TempBasisSoll
WW-Temp-Soll
</pre>

== Set-Commands ==
There is only one parameter that can be changed:
<pre>
Hzg-TempBasisSoll
</pre>

== Supported readings ==
The module extracts the following readings from the heat pump:
<pre>
Versions-Nummer
Temp-Aussen
Temp-Ruecklauf-Soll
Temp-Ruecklauf
Temp-Vorlauf
Temp-WW-Soll
Temp-WW
Temp-Raum
Temp-WQuelle-Ein
Temp-WQuelle-Aus
Temp-Verdampfer
Temp-Kondensator
Temp-Saugleitung
Druck-Verdampfer
Druck-Kondensator
Hzg-TempEinsatz
Hzg-TempBasisSoll
Hzg-KlSteilheit
Hzg-KlBegrenz
Hzg-TempRlSoll
Hzg-TempRlIst
Hzg-TmpRaumSoll
Hzg-RaumEinfluss
Hzg-ExtAnhebung
Hzg-Zeit-Ein
Hzg-Zeit-Aus
Hzg-AnhebungEin
Hzg-AnhebungAus
Hzg-St2Begrenz
Hzg-Hysterese
Hzg-PumpenNachl
Klg-Abschaltung
Klg-Temp-Einsatz
Klg-TeBasisSoll
Klg-KlSteilheit
Klg-KlBegrenz
Klg-KlSollwert
Klg-Temp-Rl
Ww-Abschaltung
Ww-Zeit-Ein
Ww-Zeit-Aus
Ww-Temp-Ist
Ww-Temp-Soll
Ww-Hysterese
Uhrzeit
Datum
BetrStundenKompressor
BetrStundenHzgPu
BetrStundenWwPu
BetrStundenSt2
Zeit
SetBetriebsMode
Display-Zeile-1
Display-Zeile-2
Status-Gesamt
Status-Heizung
Status-Kuehlung
Mode-Heizung
Mode-Kuehlung
Mode-Warmwasser
Heizung
Kuehlung
Warmwasser
</pre>

== Attributes ==
;do_not_notify
: ...
;readingFnAttributes
: ...

[[Kategorie:Other Components]]
[[Kategorie:Heizungssteuerung]]

Waterkotte heat pump with Resümat CD4

2019-04-21T12:27:18Z

ZDX: Zeilenumbruch korrigiert

{{Infobox Modul
|ModPurpose=Control / Extract information from Waterkotte Heat pumps with Resümat CD4 controller
|ModType=contrib
|ModCmdRef=WKRCD4
|ModForumArea=Sonstiges
|ModFTopic=17658
|ModTechName=98_WKRCD4.pm
|ModOwner=StefanStrobel ({{Link2FU|3960|Forum}} / [[Benutzer:StefanStrobel|Wiki]])
}}
WKRCD4 allows to control / communicate with older heat pumps from Waterkotte that have a control unit called Resümat CD4 with an RS232 serial interface. Newer heat pumps from Waterkotte typically have a modbus interface that can be controlled with module [[ModbusAttr]].
CD4 control units with software version 7000, 8000 or 8011 have to be controlled with [https://forum.fhem.de/index.php/topic,83006.msg886622.html#msg886622 another version] of the WKRCD4 module.

== Availability ==
The module has been checked in to the contrib area.

== Prerequisites ==
This module requires Device::SerialPort or Win32::SerialPort module.

== Define ==
<pre>
define <name> WKRCD4 <devicename@speed> <Interval>
</pre>
The module connects to the heat pump through a serial interface and actively requests data from the heat pump every <Interval> seconds

=== Example:===

<pre>
define WP WKRCD4 /dev/dualser0@9600 60
attr WP stateFormat Status
attr WP event-min-interval .*:3600
attr WP event-on-change-reading .*
</pre>

== Configuration of the module ==
Apart from the serial interface and the interval there is nothing that needs to be defined.

== Get-Commands ==
There are only two parameters for which an explicit GET has been implemented. Most values are just readings that are automatically requested:
<pre>
Hzg-TempBasisSoll
WW-Temp-Soll
</pre>

== Set-Commands ==
There is only one parameter that can be changed:
<pre>
Hzg-TempBasisSoll
</pre>

== Supported readings ==
The module extracts the following readings from the heat pump:
<pre>
Versions-Nummer
Temp-Aussen
Temp-Ruecklauf-Soll
Temp-Ruecklauf
Temp-Vorlauf
Temp-WW-Soll
Temp-WW
Temp-Raum
Temp-WQuelle-Ein
Temp-WQuelle-Aus
Temp-Verdampfer
Temp-Kondensator
Temp-Saugleitung
Druck-Verdampfer
Druck-Kondensator
Hzg-TempEinsatz
Hzg-TempBasisSoll
Hzg-KlSteilheit
Hzg-KlBegrenz
Hzg-TempRlSoll
Hzg-TempRlIst
Hzg-TmpRaumSoll
Hzg-RaumEinfluss
Hzg-ExtAnhebung
Hzg-Zeit-Ein
Hzg-Zeit-Aus
Hzg-AnhebungEin
Hzg-AnhebungAus
Hzg-St2Begrenz
Hzg-Hysterese
Hzg-PumpenNachl
Klg-Abschaltung
Klg-Temp-Einsatz
Klg-TeBasisSoll
Klg-KlSteilheit
Klg-KlBegrenz
Klg-KlSollwert
Klg-Temp-Rl
Ww-Abschaltung
Ww-Zeit-Ein
Ww-Zeit-Aus
Ww-Temp-Ist
Ww-Temp-Soll
Ww-Hysterese
Uhrzeit
Datum
BetrStundenKompressor
BetrStundenHzgPu
BetrStundenWwPu
BetrStundenSt2
Zeit
SetBetriebsMode
Display-Zeile-1
Display-Zeile-2
Status-Gesamt
Status-Heizung
Status-Kuehlung
Mode-Heizung
Mode-Kuehlung
Mode-Warmwasser
Heizung
Kuehlung
Warmwasser
</pre>

== Attributes ==
;do_not_notify
: ...
;readingFnAttributes
: ...

[[Kategorie:Other Components]]
[[Kategorie:Heizungssteuerung]]

Waterkotte heat pump with Resümat CD4

2019-04-21T12:26:34Z

ZDX: Hinweis für Software-Version 7000/8000/8011 hinzugefügt.

{{Infobox Modul
|ModPurpose=Control / Extract information from Waterkotte Heat pumps with Resümat CD4 controller
|ModType=contrib
|ModCmdRef=WKRCD4
|ModForumArea=Sonstiges
|ModFTopic=17658
|ModTechName=98_WKRCD4.pm
|ModOwner=StefanStrobel ({{Link2FU|3960|Forum}} / [[Benutzer:StefanStrobel|Wiki]])
}}
WKRCD4 allows to control / communicate with older heat pumps from Waterkotte that have a control unit called Resümat CD4 with an RS232 serial interface. Newer heat pumps from Waterkotte typically have a modbus interface that can be controlled with module [[ModbusAttr]].

CD4 control units with software version 7000, 8000 or 8011 have to be controlled with [https://forum.fhem.de/index.php/topic,83006.msg886622.html#msg886622 another version] of the WKRCD4 module.

== Availability ==
The module has been checked in to the contrib area.

== Prerequisites ==
This module requires Device::SerialPort or Win32::SerialPort module.

== Define ==
<pre>
define <name> WKRCD4 <devicename@speed> <Interval>
</pre>
The module connects to the heat pump through a serial interface and actively requests data from the heat pump every <Interval> seconds

=== Example:===

<pre>
define WP WKRCD4 /dev/dualser0@9600 60
attr WP stateFormat Status
attr WP event-min-interval .*:3600
attr WP event-on-change-reading .*
</pre>

== Configuration of the module ==
Apart from the serial interface and the interval there is nothing that needs to be defined.

== Get-Commands ==
There are only two parameters for which an explicit GET has been implemented. Most values are just readings that are automatically requested:
<pre>
Hzg-TempBasisSoll
WW-Temp-Soll
</pre>

== Set-Commands ==
There is only one parameter that can be changed:
<pre>
Hzg-TempBasisSoll
</pre>

== Supported readings ==
The module extracts the following readings from the heat pump:
<pre>
Versions-Nummer
Temp-Aussen
Temp-Ruecklauf-Soll
Temp-Ruecklauf
Temp-Vorlauf
Temp-WW-Soll
Temp-WW
Temp-Raum
Temp-WQuelle-Ein
Temp-WQuelle-Aus
Temp-Verdampfer
Temp-Kondensator
Temp-Saugleitung
Druck-Verdampfer
Druck-Kondensator
Hzg-TempEinsatz
Hzg-TempBasisSoll
Hzg-KlSteilheit
Hzg-KlBegrenz
Hzg-TempRlSoll
Hzg-TempRlIst
Hzg-TmpRaumSoll
Hzg-RaumEinfluss
Hzg-ExtAnhebung
Hzg-Zeit-Ein
Hzg-Zeit-Aus
Hzg-AnhebungEin
Hzg-AnhebungAus
Hzg-St2Begrenz
Hzg-Hysterese
Hzg-PumpenNachl
Klg-Abschaltung
Klg-Temp-Einsatz
Klg-TeBasisSoll
Klg-KlSteilheit
Klg-KlBegrenz
Klg-KlSollwert
Klg-Temp-Rl
Ww-Abschaltung
Ww-Zeit-Ein
Ww-Zeit-Aus
Ww-Temp-Ist
Ww-Temp-Soll
Ww-Hysterese
Uhrzeit
Datum
BetrStundenKompressor
BetrStundenHzgPu
BetrStundenWwPu
BetrStundenSt2
Zeit
SetBetriebsMode
Display-Zeile-1
Display-Zeile-2
Status-Gesamt
Status-Heizung
Status-Kuehlung
Mode-Heizung
Mode-Kuehlung
Mode-Warmwasser
Heizung
Kuehlung
Warmwasser
</pre>

== Attributes ==
;do_not_notify
: ...
;readingFnAttributes
: ...

[[Kategorie:Other Components]]
[[Kategorie:Heizungssteuerung]]

HomeMatic Wired

2019-04-04T17:04:24Z

ZDX: /* Aktoren / Sensoren */ Schreibfehler korrigiert

'''HomeMatic Wired''' (HMW / HM485) ist ein auf RS485 basierendes Bussystem für die Hausautomation. Die Auswahl an Aktoren und Sensoren ist im Vergleich zum [[HomeMatic]]-Funksystem geringer. Die wichtigsten Funktionen wie Lichtsteuerung, Rollläden, Tür- / Fenstersensoren, Schalter und Taster lassen sich aber integrieren. Über verschiedene I/O-Module lassen sich viele weitere Geräte anschließen. Auch analoge Messwerte können ausgewertet werden, so dass hier z.B. auch Temperatursensoren integriert werden könnten.

Alle Module sind rückkanalfähig, d.h. es erfolgt eine Rückmeldung, wenn ein Gerät eine Nachricht erhalten hat (''ACK'' für '''Ack'''nowledgement, also Empfangsbestätigung). Auch werden externe Zustandsänderungen der Geräte unmittelbar über den Bus weitergeleitet (bei den meisten Geräten ist letzteres abschaltbar).

Alle HMW-Module werden über den Bus mit Energie versorgt. Batteriebetriebene Module sind nicht vorgesehen und auch nicht sinnvoll, da HMW ein kabelgebundenes System ist.

== Installation und Upgrade in FHEM ==
Für den Einsatz mit FHEM benötigt man die entsprechende [[:Kategorie:Server_Hardware|Rechner-Hardware]], FHEM selbst und einen Übertragungs- bzw. Konfigurationsadapter ([[Interface]]) wie z.B. einen [[Serial/Netzwerk-RS485-Adapter]] oder das [[HomeMatic Wired RS485 LAN Gateway]], wobei letzteres nicht wirklich empfohlen werden kann.

HM485 ist nicht automatisch Teil von FHEM. Es muss explizit installiert bzw. hinzugefügt werden. Die Installation funktioniert folgendermaßen:
* Falls man sich seiner Sache nicht ganz sicher ist, empfiehlt sich zuerst ein Backup der FHEM-Installation.
* HM485 benötigt das Perl-Modul XML::Simple. Unter Debian (inklusive normaler Raspberry-Installationen) ist dieses Modul im Paket libxml-simple-perl enthalten, kann also mittels <code>apt-get install libxml-simple-perl</code> (auf Betriebssystemebene als root) installiert werden. Ansonsten kann es z.B. über Cpan installiert werden.
* Falls man den letzten FHEM-Update vor dem 24.12.2015 gemacht hat, dann muss man vor der HM485-Installation einen Update durchführen. Also im Kommandofeld eingeben:<code>update</code> Dann den Update-Vorgang abwarten und Neustarten:<code>shutdown restart</code>.
* Dann das HM485-Repository zum FHEM Update hinzufügen:
** <code>update add https://raw.githubusercontent.com/kc-GitHub/FHEM-HM485/master/controls_hm485.txt</code>
* Jetzt <code>update force hm485</code> und <code>shutdown restart</code>. HM485 sollte jetzt installiert sein.
* Es muss jetzt noch sichergestellt werden, dass das Programm HM485d.pl (im Verzeichnis FHEM/lib/HM485/HM485d) für den User fhem ausführbar ist. Das ist normalerweise nicht automatisch der Fall. Es muss im Zweifelsfall per <code>sudo chmod a+x HM485d.pl</code> ausführbar gemacht werden.

Zum Upgrade reicht ein <code>update</code>, wenn man HM485 wie oben beschrieben installiert hat. Ansonsten kann man auch das HM485-Repository nachträglich eintragen wie oben beschrieben. Wenn man von einer manuellen Installation auf die "update add"-Variante wechselt, dann sollte man das erste Mal immer <code>update force hm485</code> machen. Will man nur den HM485-Teil aktualisieren und nicht alles in FHEM, dann geht das mit <code>update all hm485</code>.

Falls es insbesondere beim Upgrade oder nach einem Upgrade Probleme gibt (welcher Art auch immer), sollten die folgenden Punkte geprüft werden:
* Wird das richtige Repository benutzt? Man kann das mit <code>update list</code> überprüfen. Wenn der Eintrag für hm485 nicht genau so aussieht wie oben beschrieben, dann sollte er per <code>update delete</code> gelöscht werden und dann genau so eingetragen werden wie oben beschrieben. Insbesondere Zwischenversionen wie "dev", "v0800" oder "thorsten" gibt es nur temporär und sollten nur zum Testen verwendet werden.
* Ist XML::Simple installiert? Siehe die Installationanleitung weiter oben für Details.
* FHEM braucht Schreibrechte im Verzeichnis <fhem>/FHEM/lib/HM485/Devices (<fhem> steht meistens für /opt/fhem) und allen Dateien und Unterverzeichnissen. Auf Betriebssystemebene (Linux) kann man das mit <code>ls -ls</code> überprüfen. Meistens kann es mit folgendem Befehl repariert werden: <code>chown -R fhem:dialout /opt/fhem/FHEM/lib/HM485/Devices</code>.
* Wenn das nicht hilft, dann kann man auch vor einem <code>shutdown restart</code> alle pm-Dateien im Devices-Verzeichnis löschen (<code>rm /opt/fhem/FHEM/lib/HM485/Devices/*.pm</code>). Diese Dateien werden beim nächsten FHEM-Start neu generiert.

== Verkabelung ==
Das folgende Bild zeigt die Verkabelung von HM-Wired am Beispiel eines seriellen USB-Adapters und zwei Geräten.
[[File:HM-Wired-Verkabelung-Digitus.jpg|border|700px|Verkabelungsbeispiel HM-Wired]]

Im Unterschied zu anderen RS485-Bussystemen wird GND immer mit verbunden. Außerdem sind die Widerstandswerte des sogenannten Busabschluss zu beachten.

== Der sogenannte Busabschluss ==

Im Gegensatz zu anderen RS485-Bussystemen braucht Homematic Wired keinen echten Busabschluss. Die Datenübertragungsrate ist zu niedrig, als dass es zu Problemen wegen Reflexionen kommt. Wahrscheinlich kann es durch den üblichen RS485-Busabschluss (etwa 120 Ohm zwischen A und B) sogar vorkommen, dass der Bus nicht richtig funktioniert oder sogar Geräte beschädigt werden.
Das, was von eq3 als Abschlusswiderstand verkauft wird, ist kein Busabschluss, sondern ein Widerstandsnetzwerk, welches den Bus auf ein definiertes Potential bringt, wenn kein Busteilnehmer sendet. Die genauen Werte können dem obigen Bild entnommen werden. Das ganze ist so berechnet, dass sich zwischen A und B in etwa ein Unterschied von 5V ergibt. (Sehe auch Homematic Inside [https://homematic-forum.de/forum/viewtopic.php?t=15128])
Wenn man jetzt noch zusätzlich 120Ohm (möglicherweise zweimal) an den Bus hängt, dann hat man in etwa 60Ohm zwischen A und B. Dadurch liegen A und B fast auf demselben Potential und man hat in etwa das Gegenteil von dem erreicht, was man eigentlich wollte.

In vielen Fällen funktioniert ein Homematic Wired System auch ohne Abschlusswiderstand, insbesondere wenn Homebrew-Geräte am Bus angeschlossen sind. Allerdings haben bisherige Erfahrungen gezeigt, dass das System mit der Zeit instabil werden kann, wenn z.B. der Bus verlängert wird oder mehr Geräte dazukommen. Für einen "produktiven" Einsatz wird daher empfohlen, einen Abschlusswiderstand zu verwenden, auch wenn es im Test oft ohne geht. Das gilt insbesondere dann, wenn man nur Original-eq3-Geräte verwendet.

Falls man nur Homebrew-Devices am Bus hat, hat man möglicherweise gar keine 24V. Dann ist auch der eq3-Abschlusswiderstand nicht sinnvoll. Es reicht dann ein einfacher Pulldown an B und ein Pullup auf 5V an A.

== Pair / Peer bzw. pairen und peeren ==
HMW-Geräte können unter- bzw. miteinander [[Peering (HomeMatic)|gepeert]] werden, wenn z.B. ein Sensor einen Aktor direkt (ohne Zentrale) steuern soll. Ein einfaches Peering zweier Kanäle kann meistens ohne Zentrale erfolgen, d.h. mit den Bedienelementen direkt an den Geräten. Allerdings ist es über die FHEM-Oberfläche in der Regel einfacher. Außerdem können dann weitere Parameter der jeweiligen Verknüpfung angegeben werden.

HMW-Geräte müssen andererseits mit einer Zentrale ''gepairt'' werden, wenn diese Zentrale die Geräte (um-)konfigurieren bzw. steuern oder zumindest auslesen können soll.

Anders als bei den HomeMatic-Funk-Geräten erfolgt dieses Pairing automatisch, sobald ein Gerät erstmalig Nachrichten über den RS485 Bus sendet. Zusätzlich besteht die Möglichkeit, über einen Discovery-Befehl alle am Bus angeschlossenen Module zu ermitteln. Auch bei diesem Vorgang erfolgt im Anschluss daran ein automatisches Pairing aller bis dahin unbekannten Geräte mit der Zentrale bzw. mit FHEM.

== Aktoren / Sensoren ==
Eine Übersicht und weitere Informationen über die von FHEM unterstützten HomeMatic-Geräte ist [[:Kategorie:HomeMatic Components| hier]] zu finden:

Hier dennoch eine dedizierte Liste aller HMW-Geräte und der benötigten Interfaces:
* [[Serial/Netzwerk-RS485-Adapter]] Netzwerk-/Serial-/USB-RS485 Adapter
* [[HomeMatic Wired RS485 LAN Gateway|HMW-LGW-O-DR-GS-EU]] HomeMatic Wired RS485 LAN Gateway, Hutschienenmontage
* ''HMW-Sen-SC-12|HMW-Sen-SC-12-DR'' HomeMatic Wired RS485 Schließerkontakt, 12 Eingänge, Hutschienenmontage
* ''HMW-Sen-SC-12|HMW-Sen-SC-12-FM'' HomeMatic Wired RS485 Schließerkontakt, 12 Eingänge, Unterputzmontage
* ''HMW-IO-12-FM'' HomeMatic Wired RS485 I/O-Modul, 12 Ein-/Ausgänge, Unterputzmontage
* [[HMW-IO-12-Sw14-DR Wired RS485 I/O-Modul 12 Eingänge 14 Ausgänge]], Hutschienenmontage
* ''HMW-LC-Sw2-DR'' HomeMatic Wired RS485-Schaltaktor 2fach, Hutschienenmontage
* [[HMW-IO-12-Sw7-DR Wired RS485 I/O-Modul 12 Eingänge 7 Ausgänge]], Hutschienenmontage
* ''HMW-IO-4-FM'' HomeMatic Wired RS485 4fach-I/O-Modul, 4 Ein-/Ausgänge, Unterputzmontage
* ''HMW-LC-Bl1-DR'' HomeMatic Wired RS485-Rollladenaktor, 1fach, Hutschienenmontage
* [[HMW-LC-Dim1L-DR Wired RS485 Dimmaktor 1fach]], Phasenanschnitt, Hutschienenmontage

Momentan werden (bzw. wurden) außerdem "HM-Homebrew" Geräte entwickelt.

{| class="wikitable"
| '''Modell'''
| '''ID'''
| '''Beschreibung'''
| '''FHEM'''
| '''CCU'''
| '''Firmware'''
|-
| [[HBW-1W-T10]]
| 0x81
| 10-fach 1-Wire Temperatursensor
| {{Link2Forum|Topic=22952|Message=207372|LinkText=ja}}
| ja
| [https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HBW-1W-T10 Git]
|-
| ''HBW-LC-Bl-4''
| 0x82
| 4-Kanal Rollladenaktor
| ja
|
| [https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-LC-BL-4 Git]
|-
| ''HBW-LC-Bl-8''
| 0x92
| 8-Kanal Rollladenaktor
| ja
|
| [https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-LC-BL-8 Git]
|-
| ''HBW-LC-Sw8''
| 0x83
| 8-fach Schaltaktor
| ja
|
| [https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-LC-Sw-8 Git]
|-
| ''HBW-LC-Sw-12''
| 0x93
| 12-fach Schaltaktor
| ja
|
| [https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-LC-Sw-12 Git]
|-
| ''HBW-Sen-EP''
| 0x84
| 8-fach S0-Interface
| ja
|
| [https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HBW-Sen-EP Git]
|-
| ''HBW-Sen-KEY''
| 0x85
| RFID-Interface
| ja
|
| [https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-KEY Git]
|-
| ''HBW-Sen-SC8''
| 0x86
| 8-fach Tasterschnittstelle
| ja
|
| [https://github.com/mago0211/HBW-RS485 Git]
|-
| {{Link2Forum|Topic=64700|Message=563558|LinkText=HBW-Sen-Key-12}}
| 0x95
| 12-fach Tasterschnittstelle
| ja
|
| [https://github.com/ThorstenPferdekaemper/HBWired Git]
|-
| {{Link2Forum|Topic=22952|Message=270160|LinkText=HBW-CC-Vd2-T}}
| 0x87
| Steuerung 24V-Ventile
| ja
|
| [https://github.com/hresalg/HBW/tree/dev/HBW_CC_Vd2_T Git]
|-
|
| 0x88
| Wettersensor
|
|
|
|-
|
| 0x89
| Tastsensor
|
|
|
|-
| {{Link2Forum|Topic=22952|Message=186435|LinkText=HBW-Sec-MDIR-2}}
| 0x91
| Bewegungsmelder-Schnittstelle
|
|
| [https://github.com/kc-GitHub/HM485-Lib/tree/rene/HBW-Sec-MDIR-2 Git]
|-
| ''HMW-LC-Sw2-DR''
| 0x11
|
| ja
| ja
| [https://github.com/kc-GitHub/HM485-Lib/blob/thorsten/HMW-LC-Sw2-DR Git], {{Link2Forum|Topic=22952|Message=251906|LinkText=Forum}}
|-
| ''HMW-LC-Bl1-DR''
| 0x15
| 1-Kanal Rollladenaktor
| ja
| ja
| [https://github.com/kc-GitHub/HM485-Lib/tree/markus/HMW-LC-Bl1-DR Git]
|-
| ''HMW-IO-12-FM''
|
|
| nein
| nein
| [https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HMW-IO-12-FM Git]
|-
| {{Link2Forum|Topic=22952|Message=275898|LinkText=HBW_LC_RGB1_CV}}
| 0xA0
| 3-fach Dimmer als RGB-Controller
| ja
| ?
| [https://github.com/BrainHunter/RGB-CTRL Git]
|-
| HBW-SD6-Multikey
| 0xB1
| Reserviert für 6-fach Taster von [http://haus-bus.de/ haus-bus.de]
| nein
| nein
| [https://github.com/haus-bus/MultitasterSD6/tree/HM-Wired Git]
|-
| {{Link2Forum|Topic=22952|Message=837275|LinkText=HBW-SC-10-Dim-6}}
| 0x96
| 6-fach Dimmer mit 10 digitalen Eingängen
|
|
| [https://github.com/loetmeister/HBWired/tree/master/HBW-SC-10-Dim-6 Git]
|-
|}

In der obigen Liste der Homematic-Wired-Homebrew Geräte kommen auch Modellbezeichnungen von Original-Homematic-Geräten vor (HMW...). In diesen Fällen handelt es sich um Homebrew-Geräte, die sich gegenüber FHEM bzw. der CCU wie das angegebene Gerät verhalten. Unter Umständen weicht aber das Verhalten von dem der Original-Geräte ab.
Die Spalten "FHEM" und "CCU" besagen, ob das entsprechende Gerät in FHEM bzw. in der CCU erkannt wird und funktioniert. Ist in beiden Spalten ein "nein" eingetragen, dann kann davon ausgegangen werden, dass das Gerät noch gar nicht funktioniert. Bei einem "ja" kann es auch noch Einschränkungen geben.

Zur Erstellung eigener HBW Geräte mittels Arduino gibt es ein {{Link2Forum|Topic=61780|LinkText=Tutorial}} von Thorsten im Forum.

== Links ==
* [https://github.com/kc-GitHub/FHEM-HM485 Github Repository] der HM485 Module (für FHEM)
* [https://github.com/kc-GitHub/FHEM-HM485/archive/master.zip aktuelle Version] der HM485 Module zum Download (für FHEM)
* [https://github.com/kc-GitHub/HM485-Lib Arduino HBW lib] wird nicht mehr aktuallisiert !!!
* [https://github.com/ThorstenPferdekaemper/HBWired Arduino HBWired lib] aktuelle Version
* {{Link2Forum|Topic=61780|LinkText=Tutorial}} zur Erstellung eigener HBW Geräte mit Arduino
* [http://www.homematic.com/ HomeMatic] Homepage
* Hersteller [http://www.eq-3.de eQ-3]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Glossary]]

Acer Beamer mit RS232

2019-02-18T11:14:28Z

ZDX: /* Bekannte Probleme */Abschnitt zu bekannten Problemen hinzugefügt

{{Infobox Modul
|ModPurpose=Ermöglicht die Steuerung von Beamern der Marke Acer über das RS232-Interface
|ModType=x
|ModCmdRef=AcerBeamer_RS232
|ModForumArea=Multimedia
|ModFTopic=95757
|ModTechName=70_AcerBeamer_RS232.pm
|ModOwner=ZDX ({{Link2FU|34515|Forum}} / [[Benutzer:ZDX|Wiki]])
}}
[[Acer Beamer mit RS232]] können mit dem Modul 70_AcerBeamer_RS232.pm gesteuert werden. Auch Informationen wie z.B. der derzeitige Eingang können abgerufen werden.

== Definition ==
<pre>
define <Name> AcerBeamer_RS232 <device@baudrate> <Interval>
</pre>
Wenn keine Baud-Rate angegeben ist wird standardmäßig 9600 verwendet - dies sollte für die meisten Beamer auch korrekt sein.
Das Modul überprüft alle ''<Interval>''-Sekunden (wenn nicht angegeben: 60) ob der Beamer derzeit eingeschaltet ist oder nicht und setzt das entsprechende Reading.

== Readings / Get-Befehle ==
* lampHours - Betriebsstunden der Lampe
* manufacturer - Hersteller/Marke des Beamers
* source - Derzeit ausgewählter Eingang
* presence - absent/present für aus/ein (Nicht direkt als get)
* state - off/on (Nicht direkt als get)

== Set-Befehle ==
* power
** on
** off

* quickSettings
** 16:9
** 4:3
** brightness
** colorRgb
** colorTemp
** contrast
** eKey
** keystone
** language

* remoteControl
** up
** down
** left
** right
** freeze
** hide
** menu
** mute
** zoom
** volUp
** volDown

* source
** auto
** resync
** dsub
** hdmi
** composite
** svideo

== Bekannte Probleme ==
Wird ein Befehl abgesetzt während eine zyklische Power-Abfrage läuft so kann es unter Umständen passieren, dass der Status des Beamers fälschlicherweise auf "off" gesetzt wird.

Bei einigen Beamern funktionieren manche Befehle eventuell nicht, bitte im Forenthread melden, wenn Probleme auftreten.

== Links ==
[http://bilder.hifi-forum.de/medium/226620/pinbelegung_195544.jpg Pinbelegung für das benötige Kabel], hifi-forum.de

[[Kategorie:Gerätemodul]]
[[Kategorie:Unterhaltungselektronik]]

Acer Beamer mit RS232

2019-02-18T11:01:08Z

ZDX: Seite erstellt, Inhalt hinzugefügt

{{Infobox Modul
|ModPurpose=Ermöglicht die Steuerung von Beamern der Marke Acer über das RS232-Interface
|ModType=x
|ModCmdRef=AcerBeamer_RS232
|ModForumArea=Multimedia
|ModFTopic=95757
|ModTechName=70_AcerBeamer_RS232.pm
|ModOwner=ZDX ({{Link2FU|34515|Forum}} / [[Benutzer:ZDX|Wiki]])
}}
[[Acer Beamer mit RS232]] können mit dem Modul 70_AcerBeamer_RS232.pm gesteuert werden. Auch Informationen wie z.B. der derzeitige Eingang können abgerufen werden.

== Definition ==
<pre>
define <Name> AcerBeamer_RS232 <device@baudrate> <Interval>
</pre>
Wenn keine Baud-Rate angegeben ist wird standardmäßig 9600 verwendet - dies sollte für die meisten Beamer auch korrekt sein.
Das Modul überprüft alle ''<Interval>''-Sekunden (wenn nicht angegeben: 60) ob der Beamer derzeit eingeschaltet ist oder nicht und setzt das entsprechende Reading.

== Readings / Get-Befehle ==
* lampHours - Betriebsstunden der Lampe
* manufacturer - Hersteller/Marke des Beamers
* source - Derzeit ausgewählter Eingang
* presence - absent/present für aus/ein (Nicht direkt als get)
* state - off/on (Nicht direkt als get)

== Set-Befehle ==
* power
** on
** off

* quickSettings
** 16:9
** 4:3
** brightness
** colorRgb
** colorTemp
** contrast
** eKey
** keystone
** language

* remoteControl
** up
** down
** left
** right
** freeze
** hide
** menu
** mute
** zoom
** volUp
** volDown

* source
** auto
** resync
** dsub
** hdmi
** composite
** svideo

== Bekannte Probleme ==
Wird ein Befehl abgesetzt während eine zyklische Power-Abfrage läuft so kann es unter Umständen passieren, dass der Status des Beamers fälschlicherweise auf "off" gesetzt wird.

== Links ==
[http://bilder.hifi-forum.de/medium/226620/pinbelegung_195544.jpg Pinbelegung für das benötige Kabel], hifi-forum.de

[[Kategorie:Gerätemodul]]
[[Kategorie:Unterhaltungselektronik]]