FHEMWiki - Benutzerbeiträge [de]

Step-by-step instructions for exemplary SMA example

2025-02-16T16:06:00Z

Krueuw: Eine Anleitung für Einsteiger in das Modul ModbusAttr am Beispiel SMA-WEechselrichter als Unterseite hinzugefügt

== Configuring Maximum AC Power Limit on the TP25000 in FHEM ==

This article explains how to configure a FHEM device using the ModbusAttr module to:

Read the current AC power (GridMs.TotW) from a TP25000 inverter.
Set (write) the maximum AC power limit (Pmax) into the inverter.

In our example, the device is renamed to AB_PV17_STP25000_MaxAC and the target maximum power is set to 2000 W.

=== Step 1: Define the Device as a Modbus Master ===

The device is defined as a Modbus master that polls every 60 seconds via TCP:
<syntaxhighlight lang="perl">
define AB_PV17_STP25000_MaxAC ModbusAttr 3 60 192.168.29.182:502 TCP
attr AB_PV17_STP25000_MaxAC dev-h-defPoll 1 </syntaxhighlight>

'''AB_PV17_STP25000_MaxAC''': Name of the FHEM device.

'''ModbusAttr 3 60 192.168.9.182:502 TCP''': Sets the device as a Modbus master with ID 3, polling every 60 seconds using Modbus TCP to the IP address 192.168.9.182 on port 502.

'''dev-h-defPoll 1''': Ensures the device is polled regularly.

=== Step 2: Configure the Read Object for the Current AC Power ===

The current power value is read from the holding register at address 30775 (GridMs.TotW):
<syntaxhighlight lang="perl">
attr AB_PV17_STP25000_MaxAC obj-h30775-reading actAC
attr AB_PV17_STP25000_MaxAC obj-h30775-len 2
attr AB_PV17_STP25000_MaxAC obj-h30775-unpack N </syntaxhighlight>

'''obj-h30775-reading actAC''': Reads the current power value from register 30775 and stores it in the reading named actAC.

'''obj-h30775-len 2''': Indicates that 2 registers (32 bits) are read.

'''obj-h30775-unpack N''': Decodes the 32‑bit value as an unsigned integer in Big‑Endian format.

=== Step 3: Configure the Write Object for the Maximum AC Power Limit ===

The maximum AC power (Pmax) is written into the holding register at address 40915 (Inverter.WMax):
<syntaxhighlight lang="perl">
attr AB_PV17_STP25000_MaxAC obj-h40915-reading maxAC
attr AB_PV17_STP25000_MaxAC obj-h40915-len 2
attr AB_PV17_STP25000_MaxAC obj-h40915-unpack N
attr AB_PV17_STP25000_MaxAC obj-h40915-set 1
attr AB_PV17_STP25000_MaxAC obj-h40915-setexpr $val
attr AB_PV17_STP25000_MaxAC obj-h40915-showGet 1 </syntaxhighlight>

'''obj-h40915-reading maxAC''': Reads/writes the target maximum power value from register 40915 and stores it in the reading maxAC.

'''obj-h40915-len 2''': Specifies that 2 registers (32 bits) are used.

'''obj-h40915-unpack N''': Decodes the 32‑bit value as unsigned in Big‑Endian format.

'''obj-h40915-set 1''': Enables writing to this object.

'''obj-h40915-setexpr $val''': Passes the entered value directly to the register.

'''obj-h40915-showGet 1''': Causes an input field for the set command to appear in the web interface.

=== Step 4: Set the Maximum AC Power ===

To limit the maximum AC power to 2000 W, execute:
<syntaxhighlight lang="bash"> set AB_PV17_STP25000_MaxAC maxAC 2000 </syntaxhighlight>

This command writes the value 2000 into register 40915, thereby setting the maximum AC power limit to 2000 W.

=== Summary ===

The device AB_PV17_STP25000_MaxAC is configured using the ModbusAttr module to:

Read the current AC power from registers starting at 30775 (2 registers, 32 bits) and store it as actAC.

Write the maximum AC power limit into registers starting at 40915 (2 registers, 32 bits).

With obj-h40915-showGet 1, an input field appears in the web interface so that you can directly enter a new value.

To monitor the current power, use: <syntaxhighlight lang="bash"> get AB_PV17_STP25000_MaxAC actAC </syntaxhighlight>

To set the maximum power to 2000 W, use: <syntaxhighlight lang="bash"> set AB_PV17_STP25000_MaxAC maxAC 2000 </syntaxhighlight>

ModbusAttr

2025-02-16T15:48:21Z

Krueuw: /* Configuration of the module as master or passive listener */

{{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>
for a relay from a serial line to a defined master or
<pre>
define <name> ModbusAttr <Id> relay <Address:Port> <RTU|ASCII|TCP> to <FhemMasterDevice>
</pre>
For a relay that listens to modbus requests from a network connection.

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 then 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.

Please note that the IP address specified in the relay definition is a local IP address of the relay itself and that the port number is 1502, not 502 because Fhem running on Linux can not easily open listening port numbers below 1024 unless it is running as root.

Other (unlikely) Example:
<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.

{{Randnotiz | RNTyp=y | RNText=To set the following attributes, modify the examples and then add them to the FHEM command line at the top of the web interface. The usual procedure in the web interface is apparently only supported afterwards.}}

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>

[[Weiteres Beispiel - SMA Wechselrichter|Another example - SMA inverter]]

[[Step-by-step instructions for exemplary SMA example]]

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

2024-04-22T20:04:45Z

Krueuw: /* Configuration of the module as master or passive listener */

{{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>
for a relay from a serial line to a defined master or
<pre>
define <name> ModbusAttr <Id> relay <Address:Port> <RTU|ASCII|TCP> to <FhemMasterDevice>
</pre>
For a relay that listens to modbus requests from a network connection.

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 then 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.

Please note that the IP address specified in the relay definition is a local IP address of the relay itself and that the port number is 1502, not 502 because Fhem running on Linux can not easily open listening port numbers below 1024 unless it is running as root.

Other (unlikely) Example:
<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.

{{Randnotiz | RNTyp=y | RNText=To set the following attributes, modify the examples and then add them to the FHEM command line at the top of the web interface. The usual procedure in the web interface is apparently only supported afterwards.}}

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>

[[Weiteres Beispiel - SMA Wechselrichter|Another example - SMA inverter]]

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]]

Weiteres Beispiel - SMA Wechselrichter

2024-04-22T20:01:10Z

Krueuw:

Based on the [https://forum.fhem.de/index.php?PHPSESSID=0r7498gqu6nfenvipunrp94feq&topic=75638.1215 discussion in the forum], here is another example that shows how the language can be changed in [https://files.sma.de/downloads/EDMx-Modbus-TI-de-16.pdf SMA inverters]. To do this, the value of the double holding register 40013 is read or set. 777 corresponds to DE, 778 to EN.<syntaxhighlight>
define SI ModbusAttr 3 10 192.168.188.38:502 TCP
attr SI closeAfterResponse 0
attr SI dev-h-defLen 2
attr SI dev-h-defPoll 0
attr SI dev-h-defRevRegs 0
attr SI dev-h-defUnpack N
attr SI dev-type-ENUM_JN-hint EN,DE
attr SI dev-type-ENUM_JN-map 777:DE,778:EN
attr SI dev-type-ENUM_JN-revRegs 0
attr SI enableControlSet 1
attr SI obj-h40013-reading Sprache
attr SI obj-h40013-set 1
attr SI obj-h40013-showGet 1
attr SI room SYSTEM->modbus
</syntaxhighlight>

Weiteres Beispiel - SMA Wechselrichter

2024-04-22T20:00:38Z

Krueuw: Translation to EN

Hier auf Basis [https://forum.fhem.de/index.php?PHPSESSID=0r7498gqu6nfenvipunrp94feq&topic=75638.1215 der Diskussion] im Forum ein weiteres Beispiel, das exemplarisch zeigt, wie bei [https://files.sma.de/downloads/EDMx-Modbus-TI-de-16.pdf SMA-Wechselrichtern] die Sprache gewechselt werden kann. Dazu wird der Wert des Doppel-Halteregisters 40013 ausgelesen bzw. gesetzt. 777 entspricht dabei DE, 778 EN. Based on the [https://forum.fhem.de/index.php?PHPSESSID=0r7498gqu6nfenvipunrp94feq&topic=75638.1215 discussion in the forum], here is another example that shows how the language can be changed in [https://files.sma.de/downloads/EDMx-Modbus-TI-de-16.pdf SMA inverters]. To do this, the value of the double holding register 40013 is read or set. 777 corresponds to DE, 778 to EN.<syntaxhighlight>
define SI ModbusAttr 3 10 192.168.188.38:502 TCP
attr SI closeAfterResponse 0
attr SI dev-h-defLen 2
attr SI dev-h-defPoll 0
attr SI dev-h-defRevRegs 0
attr SI dev-h-defUnpack N
attr SI dev-type-ENUM_JN-hint EN,DE
attr SI dev-type-ENUM_JN-map 777:DE,778:EN
attr SI dev-type-ENUM_JN-revRegs 0
attr SI enableControlSet 1
attr SI obj-h40013-reading Sprache
attr SI obj-h40013-set 1
attr SI obj-h40013-showGet 1
attr SI room SYSTEM->modbus
</syntaxhighlight>

ModbusAttr

2024-04-22T19:54:24Z

Krueuw: SMA-Beispiel ergänzt als Link

{{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>
for a relay from a serial line to a defined master or
<pre>
define <name> ModbusAttr <Id> relay <Address:Port> <RTU|ASCII|TCP> to <FhemMasterDevice>
</pre>
For a relay that listens to modbus requests from a network connection.

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 then 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.

Please note that the IP address specified in the relay definition is a local IP address of the relay itself and that the port number is 1502, not 502 because Fhem running on Linux can not easily open listening port numbers below 1024 unless it is running as root.

Other (unlikely) Example:
<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.

{{Randnotiz | RNTyp=y | RNText=To set the following attributes, modify the examples and then add them to the FHEM command line at the top of the web interface. The usual procedure in the web interface is apparently only supported afterwards.}}

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>

[[Weiteres Beispiel - SMA Wechselrichter]]

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]]

Weiteres Beispiel - SMA Wechselrichter

2024-04-22T19:52:13Z

Krueuw: Ein weiteres Beispiel für die Konfiguration eines FHEM-Modbus-Clients der auf einen SMA-Wechselrichter zugreift

ModbusAttr

2024-04-14T18:01:46Z

Krueuw: /* Configuration of the module as master or passive listener */

{{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>
for a relay from a serial line to a defined master or
<pre>
define <name> ModbusAttr <Id> relay <Address:Port> <RTU|ASCII|TCP> to <FhemMasterDevice>
</pre>
For a relay that listens to modbus requests from a network connection.

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 then 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.

Please note that the IP address specified in the relay definition is a local IP address of the relay itself and that the port number is 1502, not 502 because Fhem running on Linux can not easily open listening port numbers below 1024 unless it is running as root.

Other (unlikely) Example:
<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.

{{Randnotiz | RNTyp=y | RNText=To set the following attributes, modify the examples and then add them to the FHEM command line at the top of the web interface. The usual procedure in the web interface is apparently only supported afterwards.}}

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]]

S7 Beispielkonfiguration

2023-06-13T19:57:39Z

Krueuw: /* FHEM-S5-Rolladensteuerung ergänzen */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich ([[Benutzer:Krueuw]]) demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

==Status von S5-Ausgängen in FHEM anzeigen (2016)==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

Die Rollläden sollen sich auch ohne FHEM durchz die S5 steuern lassen. Dazu wird die bisherige Ein-Taster-Bedienung modifiziert. Mit dem Taster wird ein Zähler inkrementiert. Die Zählstände werden den Zuständen STOP-HEBEN-STOP-SENKEN zugeordnet. Durch Setzen auf definierte Zählerstände durch FHEM-Merker ist parallel ein Zugriff mit FHEM möglich. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''<blockquote>
<code>Kommentar : ROLLOCTRL FB4

<code>NETZWERK 1

<code> NAME :ROLLO-CT

<code> BEZ :TOGG E/A/D/B/T/Z: E BI/BY/W/D: BI

<code> BEZ :UP E/A/D/B/T/Z: A BI/BY/W/D: BI

<code> BEZ :STOP E/A/D/B/T/Z: A BI/BY/W/D: BI

<code> BEZ :DOWN E/A/D/B/T/Z: A BI/BY/W/D: BI

<code> BEZ :CTR E/A/D/B/T/Z: Z

<code> BEZ :M1 E/A/D/B/T/Z: A BI/BY/W/D: BI

<code> BEZ :M2 E/A/D/B/T/Z: A BI/BY/W/D: BI

<code>001A :

<code>001B :***

<code>NETZWERK 2 Pro Tastimpuls CTR inkrementier

<code>001C :U = TOGG

<code>001D :SSV = CTR

<code>001E :***

<code>NETZWERK 3 Von 0 bis 3 zaehlen

<code>001F :L = CTR

<code>0020 :L KZ 003

<code>0022 :>F

<code>0023 :RD = CTR

<code>0024 :***

<code>NETZWERK 4 Abfrage auf positive Flanke UP

<code>0025 :U = UP

<code>0026 :L KZ 001

<code>0028 :SVZ = CTR

<code>0029 :RB = UP

<code>002A :

<code>002B :***

<code>NETZWERK 5 Abfrage auf postive Flanke Stop

<code>002C :U = STOP

<code>002D :RD = CTR

<code>002E :RB = STOP

<code>002F :***

<code>NETZWERK 6 Abfrage auf positive Flanke Down

<code>0030 :U = DOWN

<code>0031 :L KZ 003

<code>0033 :SVZ = CTR

<code>0034 :RB = DOWN

<code>0035 :

<code>0036 :***

<code>NETZWERK 7 Bei CTR=1 Heben

<code>0037 :L = CTR

<code>0038 :L KZ 001

<code>003A :!=F

<code>003B := = M1

<code>003C :***

<code>NETZWERK 8 Bei CTR=3 Senken

<code>003D :L = CTR

<code>003E :L KZ 003

<code>0040 :!=F

<code>0041 := = M2

<code>0042 :BE</blockquote><blockquote>Kommentar : PB4

Autor : krueuw

Erstellt : Geaendert am: BIB:

NETZWERK 1 EG NW-Zimmer

0000 :SPA FB 4

0001 NAME :ROLLO-CT

0002 TOGG > E 65.2 (E/BI)

0003 UP > M 176.3 (A/BI)

0004 STOP > M 177.3 (A/BI)

0005 DOWN > M 178.3 (A/BI)

0006 CTR > Z 10 (Z/)

0007 M1 > A 11.4 (A/BI)

0008 M2 > A 11.5 (A/BI)

0009 :***

:BE</blockquote>'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

Dann ist der Weg für die Steuerung über die Module ROLLO und ASC frei:
[[Datei:Rollo-Konfiguration.png|alternativtext=x|links|1539x1539px]]

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil {{Link2Forum|Topic=56881|LinkText=haklige Fremdsoftware-Installationen}} direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die {{Link2Forum|Topic=11709|LinkText=wackligeren Varianten}} entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Device so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmessstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im {{Link2Forum|Topic=21473|LinkText=Forum}} empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind {{Link2Forum|Topic=56881|LinkText=hier}} dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

Ausschnitt aus der [[Konfiguration]], komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:
<syntaxhighlight lang="YAML>
networks:
 - fhem-network
devices:
 # - "/dev/ttyUSB0:/dev/ttyUSB0"
- "/dev/ttyAMA0:/dev/ttyAMA0"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"
</syntaxhighlight>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls, Volker Kettenbach, hat dafür in '''{{Link2Forum|Topic=114284|LinkText=diesem Forenbeitrag}}''' eine Lösung vorgeschlagen, die ich hier realisiert habe. Die zugehörige Definition: '''[[raspi docker-compose.yml]]'''.

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:
:<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [[SVG-Plots_von_FileLog_auf_DbLog_umstellen|Umstellung]] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen. Ich benutze dazu einen Raspi mit Raspi-OS und GUI. Nachdem man einen externen SD-Card-Reader angeschlossen hat, kann die eingelegte Karte direkt mit einem Befehl der GUI dupliziert werden.

==== Raspi-Alternative x64-ThinClient integrieren (2023) ====
Auf Raspis läuft viele Software, aber keine Programmiersoftware für Simatic S5. Ein Artikel in
[https://www.heise.de/select/ct/2023/6/2301013201757655367 c't 6/2023 S. 34] erläuert eine ausgesuchte kompatible Alternative, die nur wenig mehr elektrische Energie benötigt und eventuell sogar preiswerter ist, einen Thin Client Fujitsu Futro S740. Damit kann die Programmiersoftware für DOS oder Windows mit Wine besser integriert werden, indem sie direkt auf dem FHEM-Server läuft. Folgende Konfigurationsschritte bin ich gegangen:

# LUbuntu LTS vom Stick installieren,
# XRDP nach Anleitung installieren -> Zugriff mit Remmina-Client variable Auflösung,
# [https://wiki.ubuntuusers.de/Wine/ wine] nach Anleitung installieren inklusive Prefix für 32 bit,
# [https://linuxconfig.org/configuring-wine-with-winetricks winetricks] installiert + winetricks corefonts ausgeführt, für passende Schriftarten,
# [https://wiki.winehq.org/Wine_User%27s_Guide#Serial_and_Parallel_Ports wine regedit] benutzt, um COM1 mit /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 zu verbinden und um die [https://www.codeweavers.com/support/wiki/linux/faq/cxoffice_othermenufontsize Menü-Schriftgröße] anzupassen.
# Programmiersoftware vom Datenträger installieren,
# Erfolgskontrolle: Programmiersoftware läuft auf FHEM-Server und hat Zugriff auf die S5,
# Docker installieren,
# Docker compose installieren,
# Multicast für SMA-Geräte,
## <code>docker network create -d macvlan -o parent=eno1 --subnet=192.168.1.0/24 --gateway=192.168.1.254 --ip-range=192.168.1.0/27 mymacvlannetwork</code>
## Forenthema '''{{Link2Forum|Topic=114284|LinkText=FHEM in Docker mit IP-Adresse aus dem Host-Subnetz - nötig für Multicastempfang}}'''
# <code>IPs 192.168.1.1 bis 192.168.1.31 im Router reserviert und vom DHCP ausgeschlossen</code>
# '''[[futro-docker-compose.yml]]''' mit für die abweichende Hardware nötigen Änderungen,
# den [https://github.com/klein0r/fhem-style-haus-automatisierung FHEM-Skin entstauben],
# Log-DB neuaufsetzen,
# Umstecken der Programmierleitung zwischen FHEM und PG ist nun nicht mehr nötig. Einfach den Compose-Stack anhalten und es kann direkt losgehen. Bei Problemen hilft eventuell:
:<code>sudo modprobe -r pl2303 && sudo modprobe pl2303</code>

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, (Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.)

Der Thin Client Fujitsu Futro S740 fühlt sich mit meiner Installation deutlich schneller als ein Raspi4 an.

[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2023-06-13T19:56:38Z

Krueuw: /* FHEM-S5-Rolladensteuerung ergänzen */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich ([[Benutzer:Krueuw]]) demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

==Status von S5-Ausgängen in FHEM anzeigen (2016)==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

Die Rollläden sollen sich auch ohne FHEM durchz die S5 steuern lassen. Dazu wird die bisherige Ein-Taster-Bedienung modifiziert. Mit dem Taster wird ein Zähler inkrementiert. Die Zählstände werden den Zuständen STOP-HEBEN-STOP-SENKEN zugeordnet. Durch Setzen auf definierte Zählerstände durch FHEM-Merker ist parallel ein Zugriff mit FHEM möglich. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''<blockquote>
<code>Kommentar : ROLLOCTRL

<code>Autor : Uwe Krueger

<code>Erstellt :12.06.2023 Geaendert am: BIB:0

<code>NETZWERK 1

<code> NAME :ROLLO-CT

<code> BEZ :TOGG E/A/D/B/T/Z: E BI/BY/W/D: BI

<code> BEZ :UP E/A/D/B/T/Z: A BI/BY/W/D: BI

<code> BEZ :STOP E/A/D/B/T/Z: A BI/BY/W/D: BI

<code> BEZ :DOWN E/A/D/B/T/Z: A BI/BY/W/D: BI

<code> BEZ :CTR E/A/D/B/T/Z: Z

<code> BEZ :M1 E/A/D/B/T/Z: A BI/BY/W/D: BI

<code> BEZ :M2 E/A/D/B/T/Z: A BI/BY/W/D: BI

<code>001A :

<code>001B :***

<code>NETZWERK 2 Pro Tastimpuls CTR inkrementier

<code>001C :U = TOGG

<code>001D :SSV = CTR

<code>001E :***

<code>NETZWERK 3 Von 0 bis 3 zaehlen

<code>001F :L = CTR

<code>0020 :L KZ 003

<code>0022 :>F

<code>0023 :RD = CTR

<code>0024 :***

<code>NETZWERK 4 Abfrage auf positive Flanke UP

<code>0025 :U = UP

<code>0026 :L KZ 001

<code>0028 :SVZ = CTR

<code>0029 :RB = UP

<code>002A :

<code>002B :***

<code>NETZWERK 5 Abfrage auf postive Flanke Stop

<code>002C :U = STOP

<code>002D :RD = CTR

<code>002E :RB = STOP

<code>002F :***

<code>NETZWERK 6 Abfrage auf positive Flanke Down

<code>0030 :U = DOWN

<code>0031 :L KZ 003

<code>0033 :SVZ = CTR

<code>0034 :RB = DOWN

<code>0035 :

<code>0036 :***

<code>NETZWERK 7 Bei CTR=1 Heben

<code>0037 :L = CTR

<code>0038 :L KZ 001

<code>003A :!=F

<code>003B := = M1

<code>003C :***

<code>NETZWERK 8 Bei CTR=3 Senken

<code>003D :L = CTR

<code>003E :L KZ 003

<code>0040 :!=F

<code>0041 := = M2

<code>0042 :BE</blockquote><blockquote>Kommentar : PB4

Autor : krueuw

Erstellt : Geaendert am: BIB:

NETZWERK 1 EG NW-Zimmer

0000 :SPA FB 4

0001 NAME :ROLLO-CT

0002 TOGG > E 65.2 (E/BI)

0003 UP > M 176.3 (A/BI)

0004 STOP > M 177.3 (A/BI)

0005 DOWN > M 178.3 (A/BI)

0006 CTR > Z 10 (Z/)

0007 M1 > A 11.4 (A/BI)

0008 M2 > A 11.5 (A/BI)

0009 :***

:BE</blockquote>'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

Dann ist der Weg für die Steuerung über die Module ROLLO und ASC frei:
[[Datei:Rollo-Konfiguration.png|alternativtext=x|links|1539x1539px]]

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil {{Link2Forum|Topic=56881|LinkText=haklige Fremdsoftware-Installationen}} direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die {{Link2Forum|Topic=11709|LinkText=wackligeren Varianten}} entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Device so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmessstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im {{Link2Forum|Topic=21473|LinkText=Forum}} empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind {{Link2Forum|Topic=56881|LinkText=hier}} dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

Ausschnitt aus der [[Konfiguration]], komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===
Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:
<syntaxhighlight lang="YAML>
networks:
 - fhem-network
devices:
 # - "/dev/ttyUSB0:/dev/ttyUSB0"
- "/dev/ttyAMA0:/dev/ttyAMA0"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"
</syntaxhighlight>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls, Volker Kettenbach, hat dafür in '''{{Link2Forum|Topic=114284|LinkText=diesem Forenbeitrag}}''' eine Lösung vorgeschlagen, die ich hier realisiert habe. Die zugehörige Definition: '''[[raspi docker-compose.yml]]'''.

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:
:<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [[SVG-Plots_von_FileLog_auf_DbLog_umstellen|Umstellung]] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen. Ich benutze dazu einen Raspi mit Raspi-OS und GUI. Nachdem man einen externen SD-Card-Reader angeschlossen hat, kann die eingelegte Karte direkt mit einem Befehl der GUI dupliziert werden.

==== Raspi-Alternative x64-ThinClient integrieren (2023) ====
Auf Raspis läuft viele Software, aber keine Programmiersoftware für Simatic S5. Ein Artikel in
[https://www.heise.de/select/ct/2023/6/2301013201757655367 c't 6/2023 S. 34] erläuert eine ausgesuchte kompatible Alternative, die nur wenig mehr elektrische Energie benötigt und eventuell sogar preiswerter ist, einen Thin Client Fujitsu Futro S740. Damit kann die Programmiersoftware für DOS oder Windows mit Wine besser integriert werden, indem sie direkt auf dem FHEM-Server läuft. Folgende Konfigurationsschritte bin ich gegangen:

# LUbuntu LTS vom Stick installieren,
# XRDP nach Anleitung installieren -> Zugriff mit Remmina-Client variable Auflösung,
# [https://wiki.ubuntuusers.de/Wine/ wine] nach Anleitung installieren inklusive Prefix für 32 bit,
# [https://linuxconfig.org/configuring-wine-with-winetricks winetricks] installiert + winetricks corefonts ausgeführt, für passende Schriftarten,
# [https://wiki.winehq.org/Wine_User%27s_Guide#Serial_and_Parallel_Ports wine regedit] benutzt, um COM1 mit /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 zu verbinden und um die [https://www.codeweavers.com/support/wiki/linux/faq/cxoffice_othermenufontsize Menü-Schriftgröße] anzupassen.
# Programmiersoftware vom Datenträger installieren,
# Erfolgskontrolle: Programmiersoftware läuft auf FHEM-Server und hat Zugriff auf die S5,
# Docker installieren,
# Docker compose installieren,
# Multicast für SMA-Geräte,
## <code>docker network create -d macvlan -o parent=eno1 --subnet=192.168.1.0/24 --gateway=192.168.1.254 --ip-range=192.168.1.0/27 mymacvlannetwork</code>
## Forenthema '''{{Link2Forum|Topic=114284|LinkText=FHEM in Docker mit IP-Adresse aus dem Host-Subnetz - nötig für Multicastempfang}}'''
# <code>IPs 192.168.1.1 bis 192.168.1.31 im Router reserviert und vom DHCP ausgeschlossen</code>
# '''[[futro-docker-compose.yml]]''' mit für die abweichende Hardware nötigen Änderungen,
# den [https://github.com/klein0r/fhem-style-haus-automatisierung FHEM-Skin entstauben],
# Log-DB neuaufsetzen,
# Umstecken der Programmierleitung zwischen FHEM und PG ist nun nicht mehr nötig. Einfach den Compose-Stack anhalten und es kann direkt losgehen. Bei Problemen hilft eventuell:
:<code>sudo modprobe -r pl2303 && sudo modprobe pl2303</code>

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, (Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.)

Der Thin Client Fujitsu Futro S740 fühlt sich mit meiner Installation deutlich schneller als ein Raspi4 an.

[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2023-06-13T19:54:35Z

Krueuw: /* FHEM-S5-Rolladensteuerung ergänzen um FB und Rollo*/

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich ([[Benutzer:Krueuw]]) demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

==Status von S5-Ausgängen in FHEM anzeigen (2016)==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

Die Rollläden sollen sich auch ohne FHEM durchz die S5 steuern lassen. Dazu wird die bisherige Ein-Taster-Bedienung modifiziert. Mit dem Taster wird ein Zähler inkrementiert. Die Zählstände werden den Zuständen STOP-HEBEN-STOP-SENKEN zugeordnet. Durch Setzen auf definierte Zählerstände durch FHEM-Merker ist parallel ein Zugriff mit FHEM möglich. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''<blockquote>
<code>Kommentar : ROLLOCTRL FB4
Autor : krueuw
Erstellt : Geaendert am: BIB:0

NETZWERK 1
NAME :ROLLO-CT
BEZ :TOGG E/A/D/B/T/Z: E BI/BY/W/D: BI
BEZ :UP E/A/D/B/T/Z: A BI/BY/W/D: BI
BEZ :STOP E/A/D/B/T/Z: A BI/BY/W/D: BI
BEZ :DOWN E/A/D/B/T/Z: A BI/BY/W/D: BI
BEZ :CTR E/A/D/B/T/Z: Z
BEZ :M1 E/A/D/B/T/Z: A BI/BY/W/D: BI
BEZ :M2 E/A/D/B/T/Z: A BI/BY/W/D: BI

001A :
001B :***

NETZWERK 2 Pro Tastimpuls CTR inkrement
001C :U = TOGG
001D :SSV = CTR
001E :***

NETZWERK 3 Von 0 bis 3 zaehlen
001F :L = CTR
0020 :L KZ 003
0022 :>F
0023 :RD = CTR
0024 :***

NETZWERK 4 Abfrage auf positive Flanke UP
0025 :U = UP
0026 :L KZ 001
0028 :SVZ = CTR
0029 :RB = UP
002A :
002B :***

NETZWERK 5 Abfrage auf postive Flanke Stop
002C :U = STOP
002D :RD = CTR
002E :RB = STOP
002F :***

NETZWERK 6 Abfrage auf positive Flanke Down
0030 :U = DOWN
0031 :L KZ 003
0033 :SVZ = CTR
0034 :RB = DOWN
0035 :
0036 :***

NETZWERK 7 Bei CTR=1 Heben
0037 :L = CTR
0038 :L KZ 001
003A :!=F
003B := = M1
003C :***

NETZWERK 8 Bei CTR=3 Senken
003D :L = CTR
003E :L KZ 003
0040 :!=F
0041 := = M2
0042 :BE</code>

</blockquote><blockquote>Kommentar : PB4

Autor : krueuw

Erstellt : Geaendert am: BIB:

NETZWERK 1 EG NW-Zimmer

0000 :SPA FB 4

0001 NAME :ROLLO-CT

0002 TOGG > E 65.2 (E/BI)

0003 UP > M 176.3 (A/BI)

0004 STOP > M 177.3 (A/BI)

0005 DOWN > M 178.3 (A/BI)

0006 CTR > Z 10 (Z/)

0007 M1 > A 11.4 (A/BI)

0008 M2 > A 11.5 (A/BI)

0009 :***

:BE</blockquote>'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

Dann ist der Weg für die Steuerung über die Module ROLLO und ASC frei:
[[Datei:Rollo-Konfiguration.png|alternativtext=x|links|1539x1539px]]

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil {{Link2Forum|Topic=56881|LinkText=haklige Fremdsoftware-Installationen}} direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die {{Link2Forum|Topic=11709|LinkText=wackligeren Varianten}} entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Device so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmessstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im {{Link2Forum|Topic=21473|LinkText=Forum}} empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind {{Link2Forum|Topic=56881|LinkText=hier}} dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

Ausschnitt aus der [[Konfiguration]], komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===
Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:
<syntaxhighlight lang="YAML>
networks:
 - fhem-network
devices:
 # - "/dev/ttyUSB0:/dev/ttyUSB0"
- "/dev/ttyAMA0:/dev/ttyAMA0"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"
</syntaxhighlight>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls, Volker Kettenbach, hat dafür in '''{{Link2Forum|Topic=114284|LinkText=diesem Forenbeitrag}}''' eine Lösung vorgeschlagen, die ich hier realisiert habe. Die zugehörige Definition: '''[[raspi docker-compose.yml]]'''.

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:
:<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [[SVG-Plots_von_FileLog_auf_DbLog_umstellen|Umstellung]] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen. Ich benutze dazu einen Raspi mit Raspi-OS und GUI. Nachdem man einen externen SD-Card-Reader angeschlossen hat, kann die eingelegte Karte direkt mit einem Befehl der GUI dupliziert werden.

==== Raspi-Alternative x64-ThinClient integrieren (2023) ====
Auf Raspis läuft viele Software, aber keine Programmiersoftware für Simatic S5. Ein Artikel in
[https://www.heise.de/select/ct/2023/6/2301013201757655367 c't 6/2023 S. 34] erläuert eine ausgesuchte kompatible Alternative, die nur wenig mehr elektrische Energie benötigt und eventuell sogar preiswerter ist, einen Thin Client Fujitsu Futro S740. Damit kann die Programmiersoftware für DOS oder Windows mit Wine besser integriert werden, indem sie direkt auf dem FHEM-Server läuft. Folgende Konfigurationsschritte bin ich gegangen:

# LUbuntu LTS vom Stick installieren,
# XRDP nach Anleitung installieren -> Zugriff mit Remmina-Client variable Auflösung,
# [https://wiki.ubuntuusers.de/Wine/ wine] nach Anleitung installieren inklusive Prefix für 32 bit,
# [https://linuxconfig.org/configuring-wine-with-winetricks winetricks] installiert + winetricks corefonts ausgeführt, für passende Schriftarten,
# [https://wiki.winehq.org/Wine_User%27s_Guide#Serial_and_Parallel_Ports wine regedit] benutzt, um COM1 mit /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 zu verbinden und um die [https://www.codeweavers.com/support/wiki/linux/faq/cxoffice_othermenufontsize Menü-Schriftgröße] anzupassen.
# Programmiersoftware vom Datenträger installieren,
# Erfolgskontrolle: Programmiersoftware läuft auf FHEM-Server und hat Zugriff auf die S5,
# Docker installieren,
# Docker compose installieren,
# Multicast für SMA-Geräte,
## <code>docker network create -d macvlan -o parent=eno1 --subnet=192.168.1.0/24 --gateway=192.168.1.254 --ip-range=192.168.1.0/27 mymacvlannetwork</code>
## Forenthema '''{{Link2Forum|Topic=114284|LinkText=FHEM in Docker mit IP-Adresse aus dem Host-Subnetz - nötig für Multicastempfang}}'''
# <code>IPs 192.168.1.1 bis 192.168.1.31 im Router reserviert und vom DHCP ausgeschlossen</code>
# '''[[futro-docker-compose.yml]]''' mit für die abweichende Hardware nötigen Änderungen,
# den [https://github.com/klein0r/fhem-style-haus-automatisierung FHEM-Skin entstauben],
# Log-DB neuaufsetzen,
# Umstecken der Programmierleitung zwischen FHEM und PG ist nun nicht mehr nötig. Einfach den Compose-Stack anhalten und es kann direkt losgehen. Bei Problemen hilft eventuell:
:<code>sudo modprobe -r pl2303 && sudo modprobe pl2303</code>

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, (Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.)

Der Thin Client Fujitsu Futro S740 fühlt sich mit meiner Installation deutlich schneller als ein Raspi4 an.

[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

Datei:Rollo-Konfiguration.png

2023-06-13T19:52:03Z

Krueuw:

ASC + ROLLO

Datei:Exemplarische ROLLO + ASC Konfiguration.png

2023-06-13T19:49:42Z

Krueuw:

Das ROLLO- bzw. das ASC-Modul steuern über S7-Merker den Rollladen.

ROLLO

2023-05-25T07:52:19Z

Krueuw: /* Attribute */

{{SEITENTITEL:ROLLO}}
{{Infobox Modul
|ModPurpose=Rollo-Steuerung zur einfachen Anzeige/Programmierung
|ModType=h
|ModFTopic=95832


|ModForumArea=Unterstützende Dienste
|ModTechName=44_ROLLO.pm
|ModOwner=KernSani}}
Das Modul [[ROLLO]] bietet eine einfache Möglichkeit, mit ein bis zwei Relais den Hoch-/Runterlauf eines Rolladen zu steuern und punktgenau anzuhalten. Außerdem wird die aktuelle Position in fhem abgebildet.
Über welche Hardware/Module die Ausgänge angesprochen werden ist dabei egal.
__TOC__
Das Modul unterstützt beliebige Konfigurationen welche Befehle ausgeführt werden müssen um die Hardware des Rollos zu steuern.

* Die Rollo-Position wird in 10%-Schritten von 0% (offen) bis 100% (geschlossen) zwischengespeichert um auf der Oberfläche für jede Position ein Icon festlegen zu können.

[[Datei:Rolladen Eintrag.PNG|right|thumb|400px|Verschiedene Ansichten des Rollo:offen, fährt gerade herunter, position 50, fährt gerade hoch, geschlossen]]
Vorteil dieses Moduls:

Ist ein Rollo mit diesem Modul definiert kann man auf der Oberfläche per Klick das Rollo hoch/runter oder auf eine bestimmte Position fahren. Der aktuelle Status des Rollo (fährt hoch/runter,offen,geschlossen,etc.) wird angezeigt.
Die Oberflächenicons werden per devStateIcon gesteuert, Icons und Farben können für jeden Status individuell formatiert werden, die Standard Kommandos auf der Oberfläche (hier: offen, geschlossen, schlitz, Position) können ebenfalls per Attribut angepasst werden. Das Status-Icon ist anklickbar.
Beim Anlegen des Moduls werden die Attribute zur Darstellung in fhem mit Standardwerten angelegt, so dass man sich einiges an Tipparbeit sparen kann, aber trotzdem die Möglichkeit hat die Darstellung individuell anzupassen.

== Voraussetzungen ==
Das eigentliche ansteuern des Rollo muss mit FHEM Befehlen ausführbar sein, diese Modul ist "nur" eine Oberfläche/Bedienmodul, kein Hardwaremodul.

Wenn ROLLO installiert wurde, bevor es Bestandteil von FHEM wurde und lange kein Update gemacht wurde, wirst du die "position" readings und das entsprechende set Kommando vermissen. "position" wurde durch "pct" ersetzt, um Kompatibilität mit anderen Modulen [https://fhem.de/commandref_DE.html#AutoShuttersControl Automatic Shutter Control - ASC] sicher zu stellen. Bitte passe deine NOTIFYs/DOIFs entsprechend an.

== Installation ==

{{Hinweis|Dieses Modul ist in der offiziellen FHEM-Auslieferung enthalten.}}

== Anwendung ==
=== Define ===
define <name> ROLLO

=== Attribute ===
{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|rl_type ||attr <Rollo-Device> rl_type [normal|HomeKit] ||||Typunterscheidung zur unterstützung verschiedener Hardware. Abhängig vom gewählten Typ wird die Richtung von der die pct gerechnet wird festgelegt:

normal = pct 0 ist offen, pct 100 ist geschlossen
HomeKit = pct 100 ist offen, pct 0 ist geschlossen
|-
|rl_secondsDown||attr <Rollo-Device> rl_secondsDown <number> ||||Sekunden zum Hochfahren
|-
|rl_secondsUp ||attr <Rollo-Device> rl_secondsUp <number> ||||Sekunden zum Herunterfahren
|-
|rl_excessTop ||attr <Rollo-Device> rl_excessTop <number> ||||Zeit, die mein Rollo fahren muss, ohne dass sich die Rollo-pct ändert (bei mir fährt der Rollo noch in die Wand, ohne dass man es am Fenster sieht, die pct ist also schon bei 0%).
|-
|rl_excessBottom ||attr <Rollo-Device> rl_excessBottom <number> ||||(siehe excessTop)
|-
|rl_switchTime ||attr <Rollo-Device> rl_switchTime <number> ||||Zeit, die zwischen 2 gegensätzlichen Laufbefehlen pausiert werden soll, also wenn der Rollo z.B. gerade runter fährt und ich den Befehl gebe hoch zu fahren, dann soll 1 Sekunde gewartet werden bis der Motor wirklich zum Stillstand kommt, bevor es wieder in die andere Richtung weiter geht. Dies ist die einzige Zeit, die nichts mit der eigentlichen Laufzeit des Motors zu tun hat, sondern ein Timer zwischen den Laufzeiten.
|-
|rl_resetTime ||attr <Rollo-Device> rl_resetTime <number> ||||Zeit, die beim Anfahren von Endpositionen (offen,geschlossen) der Motor zusätzlich an bleiben soll, um sicherzustellen, dass die Endposition wirklich angefahren wurde. Dadurch können Differenzen in der Positionsberechnung korrigiert werden.
|-
|rl_reactionTime ||attr <Rollo-Device> rl_reactionTime <number> ||||Zeit für den Motor zum Reagieren
|-
|rl_autoStop ||attr <Rollo-Device> rl_autoStop [0|1] ||||Es muss kein Stop-Befehl ausgeführt werden, das Rollo stoppt von selbst.
|-
|rl_commandUp ||attr <Rollo-Device> rl_commandUp <string> ||||Es werden bis zu 3 beliebige Befehle zum Hochfahren ausgeführt
|-
|rl_commandDown ||attr <Rollo-Device> rl_commandDown <string> ||||Es werden bis zu 3 beliebige Befehle zum Runterfahren ausgeführt
|-
|rl_commandStop ||attr <Rollo-Device> rl_commandStop <string> ||||Befehl der zum Stoppen ausgeführt wird, sofern nicht commandStopDown bzw. commandStopUp definiert sind
|-
|rl_commandStopDown ||attr <Rollo-Device> rl_commandStopDown <string> ||||Befehl der zum Stoppen ausgeführt wird, wenn der Rollo gerade herunterfährt. Wenn nicht definiert wird commandStop ausgeführt
|-
|rl_commandStopUp ||attr <Rollo-Device> rl_commandStopUp <string> ||||Befehl der zum Stoppen ausgeführt wird,wenn der Rollo gerade hochfährt. Wenn nicht definiert wird commandStop ausgeführt
|-
|rl_blockMode ||attr <Rollo-Device> rl_blockMode [blocked|force-open|force-closed|only-up|only-down|half-up|half-down|none] ||||wenn ich den Befehl blocked ausführe, dann wird aufgrund der blockMode-Art festgelegt wie mein Rollo reagieren soll:

blocked = Rollo lässt sich nicht mehr bewegen
force-open = bei einem beliebigen Fahrbefehl wird Rollo hochgefahren
force-closed = bei einem beliebigen Fahrbefehl wird Rollo runtergefahren
only-up = Befehle zum runterfahren werden ignoriert
only-down = Befehle zum hochfahren werden ignoriert
half-up = es werden nur die Positionen 50-100 angefahren, bei pct <50 wird pct 50% angefahren,
half-down = es werden nur die Positionen 0-50 angefahren, bei pct >50 wird pct 50 angefahren
none = block-Modus ist deaktiviert
|-
|automatic-enabled ||attr <Rollo-Device> automatic-enabled [on|off] ||||Wenn auf off gestellt, haben Befehle über Modul ROLLO_Automatic keine Auswirkungen auf diesen Rollo
|-
|automatic-delay ||attr <Rollo-Device> automatic-delay <number> ||||Dieses Attribut wird nur für die Modulerweiterung ROLLADEN_Automatic benötigt.
Hiermit kann einge Zeitverzögerung für den Rolladen eingestellt werden, werden die Rolladen per Automatic heruntergefahren, so wird dieser um die angegebenen Minuten später heruntergefahren.
|-
|rl_forceDrive ||attr <Rollo-Device> rl_forceDrive [0|1] ||||open/closed wird ausgeführt, auch wenn das ROLLO bereits in der Zielposition ist
|-
|rl_noSetPosBlocked ||attr <Rollo-Device> rl_noSetPosBlocked [0|1] ||||Wenn deaktiviert, können Positionsn (pct) auch gesetzt werden, wenn der ROLLO geblockt ist. Nach dem unblocken wird die entsprechende Position angefahren.
|-
|||disableattr <Rollo-Device> disable [0|1] ||||Wenn deaktiviert, können keine set oder get commandos für den ROLLO ausgeführt werden.
|-
|||||||
|-
|||||||
|-
|||||||
|}

=== Set ===

{|class="wikitable"
|-
!Name !!set Befehl !!Beschreibung
|-
|open ||set <Rollo-Device> open ||Fährt das Rollo komplett auf (pct 0)
|-
|closed ||set <Rollo-Device> closed||Fährt das Rollo komplett zu (pct 100)
|-
|up ||set <Rollo-Device> up ||Fährt das Rollo um 10 auf (pct +10)
|-
|down ||set <Rollo-Device> down ||Fährt das Rollo um 10 zu (pct -10)
|-
|half || set <Rollo-Device> half ||Fährt das Rollo zur Hälfte runter bzw. hoch (pct 50)
|-
|stop ||set <Rollo-Device> stop ||Stoppt das Rollo
|-
|drive ||set <Rollo-Device> drive up 5||Fährt das Rollo in die angegebene Richtung für die angegebene Zeit (in Sekunden)
|-
|blocked ||set <Rollo-Device> blocked ||wenn aktiviert, kann der ROLLO nur noch eingeschränkt gesteuert werden. Siehe Attribut block_mode für Details.
|-
|unblocked ||set <Rollo-Device> unblocked ||Aktiviert einen geblockten ROLLO wieder für die normale Benutzung
|-
|pct ||set <Rollo-Device> pct <value> ||Fährt das Rollo auf eine beliebige pct zwischen 0 (offen) - 100 (geschlossen)
|-
|reset ||set <Rollo-Device> reset <value> ||Sagt dem Modul in welcher pct sich der Rollo befindet
|-
|extern ||set <Rollo-Device> extern <value> ||Der Software mitteilen dass gerade Befehl X bereits ausgeführt wurde und nun z.B,. das berechnen der aktuellen pct gestartet werden soll
|}

=== Get ===

{|class="wikitable"
|-
!Name !!set Befehl !!Beschreibung
|-
|version ||get <Rollo-Device> version ||Gibt die version des Modul Rollos aus
|}

=== Readings ===
{|class="wikitable"
|-
!Name !!Wert !!Beschreibung
|-
|command||open,stop,closed||
|-
|desired_pct||0-100||Zielposition die angefahren werden soll (nur sinnvoll während das Rollo fährt)
|-
|drive-type||modul,extern||bei dem Befehl "set rollo extern .." wird dieses attribut auf "extern" gestellt, sonst immer "modul"
|-
|last_drive||drive-up,drive-down||die zuletzt benutzte Fahrtrichtung
|-
|pct||0-100||exakte Position des Rollo
|-
|state||open,closed,position-[0-100]||die Position gerundet auf ganze 10% Schritte, identisch mit dem Internal STATE
|}

== Anwendungsbeispiele ==
===Set===
set RolladenWohnzimmer pct 50
set RolladenWohnzimmer geschlossen
set RolladenWohnzimmer offen
Drei Beispiele das Rollo-Modul anzuweisen verschiedene Positionen anzufahren.

set RolladenWohnzimmer extern stop
Das Rollo-Modul wird angewiesen den status auf "nicht fahren" zu setzen, die aktuelle Rollo-Position zu berechnen und als neue Position abzuspeichern. Der eigentliche Rollo-Stop-Befehl wird dabei aber nicht gesendet.

set RolladenWohnzimmer reset closed
In der Oberfläche von fhem wird für das Rollo die Position "geschlossen" gespeichert, ohne Berechnungen durchzuführen oder Hardware zu steuern. Wird evtl. benötigt wenn der Ist-Status von den Soll-Werten aus fhem abweicht.

===Zusammenspiel mit externem Taster===
In einem Anwendungszenario hat ein Nutzer zusätzliche Taster an seinem Rollo-Motor über die er ihn ebenfalls steuern kann.
Die Taster selber senden keine Events an fhem, nur der Rollo-Motor.
Hier ein Beispiel wie das ganze für aussehen könnte und diese Taster in das ROLLO-Modul integriert werden:

define rollo_manuell_auf DOIF ([meinRollo_Kanal1] eq "on" and [?meinRolloModul] ne "drive-up") (set meinRolloModul extern open) DOELSEIF ([meinRollo_Kanal1] eq "off" and [?meinRolloModul] eq "drive-up") (set meinRolloModul extern stop)
define rollo_manuell_ab DOIF ([meinRollo_Kanal2] eq "on" and [?meinRolloModul] ne "drive-down") (set meinRolloModul extern closed) DOELSEIF ([meinRollo_Kanal2] eq "off" and [?meinRolloModul] eq "drive-down") (set meinRolloModul extern stop)

meinRollo_Kanal1 und meinRollo_Kanal2 sind die Hardwarekanäle die in dem Rollo-Modul zum hochfahren/runterfahren benutzt werden.
Das erste DOIF prüft ob das Rollo hoch fährt, ohne das das Rollo-Modul davon etwas weis. Ist dem so wird dem Rollo Modul mithilfe des set <extern> mitgeteilt das das Rollo bereits gestartet wurde. Das Modul fängt an die Zeit zu zählen und aktualisiert den Status der Oberfläche auf "fahre hoch".
IM DOELSEIF wird abgefragt ob das Rollo steht, obwohl das Modul denkt das Rollo würde noch fahren. Ist dem so wird wieder mithilfe des set <extern> dem Modul mitgeteilt das das Rollo gestoppt wurde. Das Modul berechnet nun aufgrund der gefahrenen Zeit die aktuelle Position und aktualisiert den Status der Oberfläche auf die Position.

Das gleiche wird dann im zweiten DOIF nochmal für das herunterfahren gemacht.

Man kann nun das Rollo sowohl über die Oberfläche als auch per Taster bedienen und fhem und der reale Ist-Status sind synchron. Auch eine gleichzeitige Bedienung ist möglich, Das Rollo startet z.B. aufgrund einer Automatisierung morgens zum hochfahren und man klickt schnell auf den Taster neben dem Bett und stoppt das ganze wieder.

== Links ==

Thread im {{Link2Forum|Topic=95832|LinkText=Forum}} seit das Modul Bestandteil der offiziellen FHEM Auslieferung ist

Thread im {{Link2Forum|Topic=47202|LinkText=Forum}} bevor das Modul Bestandteil von FHEM war

Grafana

2023-04-29T18:00:33Z

Krueuw: Randnotiz für den ersten Start eingefügt.

{{Randnotiz|RNText=Grafana beschreibt sich als "The open platform for beautiful analytics and monitoring".
Eine Live Demo zum Erkunden findet man im Internet unter [http://play.grafana.org play.grafana.org]}}

== Einführung ==
Die [[Grafana]]-Software stellt einen Server zur Verfügung, mit dem Zeitreihen von Zahlenwerten auf sehr handliche Weise dargestellt und manipuliert werden können. Die Auswahl bestimmter Zeitfenster, das Anlegen von Dashboards und die Gestaltung der Achsen (Minimum. Maximum) ist so sehr einfach möglich. Zudem gibt es verschiedene Paneltypen, die neben dem klassischen Chart (Line / Bar / Point) auch Pie Charts oder Tabellen beinhalten. Seit November 2017 kann Grafana mit MySQL umgehen, was eine Einbindung in FHEM (via DBLog) ermöglicht. Die Benutzeroberfläche lädt sehr schnell und ist auf vielen Geräten flüssig und einfach zu bedienen.

== Installation ==
Hier sind mehrere Schritte (einmalig) durchzuführen. Für Grafana muss ein eigener Server installiert werden und für die Grafiken müssen MySQL-Queries angelegt werden.

=== Installation und Einrichtung einer DBLog Instanz mit MySQL ===
Details sind auf der Seite [[DbLog#Beispiel:_Anlegen_und_Nutzung_einer_Mysql-Datenbank|Anlegen einer MySQL_Datenbank]] beschrieben.

Wenn schon eine Datenbank angelegt wurde und man Daten umziehen muss, helfen andere Einträge weiter.
Sollen zum Beispiel Altdaten aus SQLite gesichert und wieder in MySQL eingespielt werden, [[DbRep - Reporting und Management von DbLog-Datenbankinhalten#Datensätze (Devices) von einer Datenbank in eine andere umziehen (Export/Import)|hilft dieser Eintrag]]. Dieses Beispiel sichert nur Logdaten für ein einzelnes Gerät und nicht für alles aus der DB. Das lässt sich aber problemlos anpassen, indem man das Attribut device in der DBRep Instanz nicht belegt.

Ein Umstieg von Filelog auf DBLog geht ebenfalls. Sollen Altdaten aus den Filelogs übertragen werden, {{Link2Forum|Topic=66383|LinkText=hilft dieser Thread}}.

=== Installation des Grafana Servers ===
Es gibt [https://grafana.com/grafana/download einen offiziellen Download]. Der ist nicht ganz unproblematisch, und will man auf einem Raspberry Pi installieren, sollten eher vorkompilierte Pakete genutzt werden. Sie sind [https://github.com/fg2it/grafana-on-raspberry/releases unter diesem Link] zu finden.

Damit Grafana automatisch mit dem System startet, muss der Grafana Server noch aktiviert werden. Bei Verwendung von Systemd wäre das mit folgendem Befehl zu erledigen:
<syntaxhighlight lang="bash">
sudo /bin/systemctl enable grafana-server
</syntaxhighlight>
Im Grafana Webinterface muss dann eine neue Datasource vom Typ MySQL angelegt werden. Die Daten der FHEM-MYSQL Datenbank eintragen (Port/User/Passwort).

Grafana lauscht per default auf Port 3000. Dies kann ein Problem sein, falls man Alexa mit Custom Skill nutzt. Dieser Dienst belegt ebenfalls schon Port 3000.
In dem Fall mit
<syntaxhighlight lang="bash">
sudo nano /etc/grafana/grafana.ini
</syntaxhighlight>
und die Konfiguration anpassen:
:<code>;http_port = 3000</code>
Hier den führenden Semicolon entfernen und den Port entsprechend abändern. Zuletzt ist die Datenbank auszuwählen, in der die Daten von FHEM abgelegt sind (grafana greift standardmäßig auf eine Datenbank mit dem Namen grafana zurück).

{{Randnotiz|RNText=http://pi:3000 im Browser zeigt die Login-Seite von Grafana.

Nach Anmeldung mit admin/admin kann das Passwort auf einen sicheren Wert geändert werden.|RNTyp=Erfolgskontrolle}}

== Erstellen von Grafiken ==
=== MySQL-Queries ===
Zeitreihen werden in Grafana durch MySQL-Queries angelegt. Jede Zeitreihe benötigt dabei einen eigenen Query. Grafana legt dabei einen Musterquery an, bei dem drei Werte geändert werden müssen.
[[Datei:Grafana_Query_anlegen.png|200px|thumb|right|Query anlegen]]

Man klickt im Dashboard von Grafana auf AddRow. Durch einen Klick auf den Titel der neuen Grafik erscheint ein Menü ("View", "Edit", "Share") und wählt Edit. Dann wählt man die FHEM-Datenbank aus, siehe Screenshot. Eine Musterabfrage sieht wie folgt aus:
<syntaxhighlight lang="SQL">
SELECT
UNIX_TIMESTAMP(< time >) as time_sec,
< column > as value,
< name > as metric
FROM < table name >
WHERE $__timeFilter(time_column)
ORDER BY < time > ASC
</syntaxhighlight>

Grafana benötigt in diesem Query mindestens drei Spalten mit der richtigen Benennung, die durch <>-Klammern vorgezeichnet sind.
* time_sec muss Zeitwerte im UNIX-Timestamp Format (Sekunden seit 01.01.1970) enthalten. Meist wählt man für < time > daher den TIMESTAMP Eintrag aus der Datenbank.
* value muss Werte für die Y-Achse liefern, welche den Zeitstempeln aus time_sec zuzuordnen sind. Meist wählt man für < column > daher den VALUE Eintrag aus der Datenbank.
* metric ist der Text, der für die Kurve in der Legende angezeigt wird. Daher ist < name > frei wählbar.

Die Namen der einzelnen Spalten werden durch FHEM selbst vergeben. Man muss also bei der Verwendung der Queries herausfinden, wie die Werte intern gespeichert werden. Das klingt schwerer als es ist, weil sich FHEM dabei an Konventionen hält, die leicht geraten werden können. Der nebenstehende Screenshot zeigt einen typischen Eintrag in der DBLog von FHEM.
[[Datei:TypischerQuery.png |200px|thumb|right|Typischer Eintrag in der DBLog]]

Beim den VALUE Einträgen von FHEM muss man beachten, dass diese (da sie auch Text beinhalten können) nicht numerisch sind. Soll schon intern im SELECT eine Berechnung durchgeführt werden wie AVG oder MIN/MAX, dann muss man hier CONVERT(VALUE, DOUBLE) oder CONVERT(VALUE, INTEGER) verwenden.

Ein Beispieleintrag sieht wie folgt aus
<syntaxhighlight lang="SQL">
SELECT
UNIX_TIMESTAMP(TIMESTAMP) as time_sec,
VALUE as value, "Kurvenbezeichnung" as metric
FROM history WHERE READING="state" AND DEVICE="MyDummy" AND $__timeFilter( TIMESTAMP )
</syntaxhighlight>

Solltet Ihr numerische Werte in einer Grafik ausgeben wollen, müsst Ihr das Text-Feld VALUE mittels '''cast(VALUE as signed)''' konvertieren
<syntaxhighlight lang="SQL">
SELECT
UNIX_TIMESTAMP(TIMESTAMP) as time_sec,
cast(VALUE as signed) as value, "Kurvenbezeichnung" as metric
FROM history WHERE READING="state" AND DEVICE="MyDummy" AND $__timeFilter( TIMESTAMP )
</syntaxhighlight>

=== Macros ===
Grafana bietet ein paar Macros die man in den MySQL Selects verwenden kann, um die zu ladenden Daten auf den angezeigten Zeitraum zu begrenzen.
* $__timeFilter(TIMESTAMP) liefert eine Überprüfung auf einen Zeitraum zurück, die man in der WHERE Bedingung verwenden kann (siehe obiges Beispiel)
* $__timeFrom() liefert den Startzeitpunkt des angezeigten Zeitraums als "YYYY-MM-DD HH:MM:SS" zurück.
* $__timeTo() liefert den Endzeitpunkt des angezeigten Zeitraums als "YYYY-MM-DD HH:MM:SS" zurück (so loggt auch DBLog in die Datenbank).
* $__unixEpochFrom() liefert den Startzeitpunkt des angezeigten Zeitraums als UNIX-Timestamp Format (Sekunden seit 01.01.1970) zurück.
* $__unixEpochTo liefert den Endzeitpunkt des angezeigten Zeitraums als UNIX-Timestamp Format (Sekunden seit 01.01.1970) zurück.

=== Beispiele ===
Sehr viele Beispiele hat Thyraz in diesem {{Link2Forum|Topic=77724|LinkText=Foreneintrag}} bereitgestellt. Eine ausführliche Erläuterung zu einen Anzeige von Differenzwerten finden sich in diesem [https://forum.fhem.de/index.php/topic,77724.msg1023943.html#msg1023943 Foreneintrag].

=== Einbindung in FHEM (und andere Seiten) ===
Die Grafiken können mit einem URL einfach in FHEM und andere Seiten eingebunden werden. Die entsprechende Adresse lautet dann
http://<URL-Grafana-Server>:3000/render/dashboard/db/<Name-des-Dashboards>?orgId=2&from=now%2Fd&to=now&panelId=1&width=750&height=300&tz=UTC%2B02%3A00
Dabei ist der Teil der URL from=now%2Fd&to=now individuell veränderbar. Standardmäßig sind das fixe Zeitpunkte (wie im Beispiel mit 1507705926296). Mit "Now" etc. kann man das dynamisch gestalten und so einen alternativen, dynamischen Plot im FHEM darstellen:
* from=now%2Fd&to=now: Today so far
* from=now-30d&to=now: Die letzten 30 Tage
* from=now-395d&to=now-365d: Die letzten 30 Tage vor einem Jahr (Temperaturvergleich zum Vorjahr z.B.)

Das entsprechende device, das in FHEMWEB die Grafik zur Verfügung stellt, ist dann weblink:
defmod <device_name> weblink image <HTTP-Adresse>:3000/render/dashboard-solo/db/<Datenbankname>?orgId=2&from=now%2Fd&to=now&panelId=1&width=750&height=300&tz=UTC%2B02%3A00

Entsprechende Attribute sind auch möglich:
attr <device-name> htmlattr width="750" height="300" frameborder="0" title="Aktueller Verlauf"

Bei FTUI würde man das Image Widget verwenden. Will man die Grafiken mit iframe einbinden, so muss zuerst in Grafana eine Sicherheitseinstellung verändert werden, die eigentlich eine solche iframe-Einbindung verhindert. Dazu fügt man im Security-Abschnitt der grafana.ini folgende Zeile ein
[security]
allow_embedding = true
und startet danach den grafana-server neu.

=== Speichern und Senden von Grafiken (z.B. mit Telegram) ===
Will man Grafiken von Grafana mit Telegram oder anderen Messenger-Programmen versenden, sind mehrere Schritte notwendig. Zuerst muss die Datei "gerendert" und lokal gespeichert werden, danach kann man sie versenden. Da das Rendern ''mehrere Sekunden'' dauern kann, sollte dieser Vorgang entweder nonblocking oder sogar außerhalb von FHEM erfolgen.

==== Erster Schritt: Rendern ====
Grafana verwendet eine Authentifizierungsmethode, die beim Rendern zu berücksichtigen ist. Tut man das nicht, so erhält man keine Grafik, sondern nur eine HTML-Datei die eben anzeigt, dass der Zugriff nicht authentifiziert erfolgte. Um sich zu authentifizieren, muss man einen neuen Nutzer anlegen und einen API-Key anfordern.

[[Datei:GrafanaAPIKey.png|200px|thumb|right|Auswahl des API-Key im Grafana-Menü]]
Im Hauptmenü von Grafana wählt man links oben unter "admin" den Eintrag API-Key aus. Dort legt man einen neuen Benutzer an und notiert sich den Schlüssel (er wird nur einmal angezeigt). Dieser Schlüssel ist eine sehr lange Zeichenkette, beispielsweise "0NWcWRCVjZtSkd81NG1EOEprdVYxRUJtZWZeyJrIjoidUNycWRCVjZtSkd0NW81NGX0=". Im Folgenden möge die Zeichenkette mit <Schluessel> bezeichnet werden.

Mit dieser Authentifizierungsschlüssel kann man nun auf Grafana zugreifen. Beispielsweise möchte man ein dashboard, das mehrere Temperaturen enthält, rendern. Dazu benötigt man nun die Zugriffsadresse dieses Dashboards. Man klickt auf die Überschrift des Boards und wählt "Share" aus. Es erscheint ein Share Panel, so wie im Screenshot angezeigt.
[[Datei:GrafanaSharePanel.png|200px|thumb|right|Grafana Share Panel]]
Unten im Panel ist ein Link mit den Worten "Direct link rendered image" zu sehen. Diesen Link notiert man. Im folgenden möge der Link mit <Link> bezeichnet werden.

Auf der Shell-Ebene würde nun der folgende Befehl das Dashboard rendern und speichern
curl -H "Authorization: Bearer <Schluessel>" "<Link>" <Dateiname>

Da in der neuen Grafana-Version das Rendern ''auf einem Raspberry Pi'' nicht ohne Weiteres unterstützt wird, kann es sein, dass die oben genannten Versuche fehlschlagen. Hier bietet sich eine andere Lösung an, die zwar nicht so elegant wie die obige ist, aber dafür funktioniert: Man installiert Firefox auf dem Raspberry und lässt ihn "headless" einen Screenshot erstellen. Dieses kann man dann weiterverarbeiten. Diese Lösung hat den Nachteil, dass dann nur die Auflösung des Raspberry erreicht wird. Dazu sind folgende Schritte noztwendig. Zuerst Firefox installieren
sudo apt install firefox-esr
danach ein neues Profil in Firefox erstellen (sonst stürzt Firefox ab), das ist sehr umständlich: Auf Hilfe gehen, dann steht dort irgendwo "install new profile" und dieses Profil beispielsweise headless_profil nennen und zuletzt kann dann endlich mit einem Terminal-Befehl ein Screenshot erstellt werden
/pfad/zu/firefox -P headless_profile -headless --screenshot <hier die www-Adresse der Webseite angeben>
Mehr dazu auf [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Headless_mode dieser Webseite]

==== Zweiter Schritt: Senden mit Telegram ====
Im zweiten Schritt soll nun die Datei gesendet werden. Dazu kann man etwa den [[TelegramBot|Telegram-Bot]] verwenden. Der Sendebefehl lautet
set <TelegramBotDevice-Name> sendImage <Dateiname>
Dabei ist der Dateiname des Bild (png-Format) anzugeben.

[[Kategorie:HOWTOS]]

S7 Beispielkonfiguration

2023-04-16T17:28:26Z

Krueuw: /* Raspi-Alternative x64-ThinClient integrieren [2023] */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls Volker Kettenbach hat dafür im [https://forum.fhem.de/index.php?topic=114284.0 Forum eine Lösung vorgeschlagen], die ich hier realisiert habe. Meine docker-compose.yml sieht dann so [[raspi docker-compose.yml]]<nowiki/>aus:

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:

<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen. Ich benutze dazu einen Raspi mit Raspi-OS und GUI. Nachdem man einen externen SD-Card-Reader angeschlossen hat, kann die eingelegte Karte direkt mit einem Befehl der GUI dupliziert werden.

==== Raspi-Alternative x64-ThinClient integrieren [2023] ====
Auf Raspis läuft viele Software, aber keine Programmiersoftware für Simatic S5. Ein Artikel in

[https://www.heise.de/select/ct/2023/6/2301013201757655367 c't 6/2023 S. 34] erläuert eine ausgesuchte kompatible Alternative, die nur wenig mehr elektrische Energie benötigt und eventuell sogar preiswerter ist, einen Thin Client Fujitsu Futro S740. Damit kann die Programmiersoftware für DOS oder Windows mit Wine besser integriert werden, indem sie direkt auf dem FHEM-Server läuft. Folgende Konfigurationsschritte bin ich gegangen:

# LUbuntu LTS vom Stick installieren,
# XRDP nach Anleitung installieren -> Zugriff mit Remmina-Client variable Auflösung,
# [https://wiki.ubuntuusers.de/Wine/ wine] nach Anleitung installieren inklusive Prefix für 32 bit,
# [https://linuxconfig.org/configuring-wine-with-winetricks winetricks] installiert + winetricks corefonts ausgeführt, für passende Schriftarten,
# [https://wiki.winehq.org/Wine_User%27s_Guide#Serial_and_Parallel_Ports wine regedit] benutzt, um COM1 mit /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 zu verbinden und um die [https://www.codeweavers.com/support/wiki/linux/faq/cxoffice_othermenufontsize Menü-Schriftgröße] anzupassen.
# Programmiersoftware vom Datenträger installieren,
# Erfolgskontrolle: Programmiersoftware läuft auf FHEM-Server und hat Zugriff auf die S5,
# Docker installieren,
# Docker compose installieren,
# Multicast für SMA-Geräte,
## <code>docker network create -d macvlan -o parent=eno1 --subnet=192.168.1.0/24 --gateway=192.168.1.254 --ip-range=192.168.1.0/27 mymacvlannetwork</code>
## <code><nowiki>https://forum.fhem.de/index.php?topic=114284.0</nowiki></code>
# <code>IPs 192.168.1.1 bis 192.168.1.31 im Router reserviert und vom DHCP ausgeschlossen</code>
#[[futro-docker-compose.yml]] mit für die abweichende Hardware nötigen Änderungen,
#den [https://github.com/klein0r/fhem-style-haus-automatisierung FHEM-Skin entstauben],
#Log-DB neuaufsetzen,
#Umstecken der Programmierleitung zwischen FHEM und PG ist nun nicht mehr nötig. Einfach den Compose-Stack anhalten und es kann direkt losgehen. Bei Problemen hilft eventuell: sudo modprobe -r pl2303 && sudo modprobe pl2303.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, (Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.)

Der Thin Client Fujitsu Futro S740 fühlt sich mit meiner Installation deutlich schneller als ein Raspi4 an.

[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2023-04-15T16:56:21Z

Krueuw: /* Raspi-Alternative x64-ThinClient integrieren [2023] */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls Volker Kettenbach hat dafür im [https://forum.fhem.de/index.php?topic=114284.0 Forum eine Lösung vorgeschlagen], die ich hier realisiert habe. Meine docker-compose.yml sieht dann so [[raspi docker-compose.yml]]<nowiki/>aus:

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:

<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen. Ich benutze dazu einen Raspi mit Raspi-OS und GUI. Nachdem man einen externen SD-Card-Reader angeschlossen hat, kann die eingelegte Karte direkt mit einem Befehl der GUI dupliziert werden.

==== Raspi-Alternative x64-ThinClient integrieren [2023] ====
Auf Raspis läuft viele Software, aber keine Programmiersoftware für Simatic S5. Ein Artikel in

[https://www.heise.de/select/ct/2023/6/2301013201757655367 c't 6/2023 S. 34] erläuert eine ausgesuchte kompatible Alternative, die nur wenig mehr elektrische Energie benötigt und eventuell sogar preiswerter ist, einen Thin Client Fujitsu Futro S740. Damit kann die Programmiersoftware für DOS per Dosbox oder für Windows für Wine besser integriert werden, indem sie direkt auf dem FHEM-Server läuft. Folgende Konfigurationsschritte bin ich gegangen:

# LUbuntu LTS vom Stick installieren,
# XRDP nach Anleitung installieren -> Zugriff mit Remmina-Client variable Auflösung,
# [https://wiki.ubuntuusers.de/Wine/ wine] nach Anleitung installieren inklusive Prefix für 32 bit,
# [https://linuxconfig.org/configuring-wine-with-winetricks winetricks] installiert + winetricks corefonts ausgeführt, für passende Schriftarten,
# [https://wiki.winehq.org/Wine_User%27s_Guide#Serial_and_Parallel_Ports wine regedit] benutzt, um COM1 mit /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 zu verbinden und um die [https://www.codeweavers.com/support/wiki/linux/faq/cxoffice_othermenufontsize Menü-Schriftgröße] anzupassen.
# Programmiersoftware vom Datenträger installieren,
# Erfolgskontrolle: Programmiersoftware läuft auf FHEM-Server und hat Zugriff auf die S5,
# Docker installieren,
# Docker compose installieren,
# Multicast für SMA-Geräte,
## <code>docker network create -d macvlan -o parent=eno1 --subnet=192.168.1.0/24 --gateway=192.168.1.254 --ip-range=192.168.1.0/27 mymacvlannetwork</code>
## <code><nowiki>https://forum.fhem.de/index.php?topic=114284.0</nowiki></code>
# <code>IPs 192.168.1.1 bis 192.168.1.31 im Router reserviert und vom DHCP ausgeschlossen</code>
#[[futro-docker-compose.yml]] mit für die abweichende Hardware nötigen Änderungen,
#den [https://github.com/klein0r/fhem-style-haus-automatisierung FHEM-Skin entstauben],
#Log-DB neuaufsetzen,
#Umstecken der Programmierleitung zwischen FHEM und PG ist nun nicht mehr nötig. Einfach den Compose-Stack anhalten und es kann direkt losgehen. Bei Problemen hilft eventuell: sudo modprobe -r pl2303 && sudo modprobe pl2303.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, (Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.)

Der Thin Client Fujitsu Futro S740 fühlt sich mit meiner Installation deutlich schneller als ein Raspi4 an.

[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2023-04-15T12:46:14Z

Krueuw: /* Multicast-Empfang mit Docker */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls Volker Kettenbach hat dafür im [https://forum.fhem.de/index.php?topic=114284.0 Forum eine Lösung vorgeschlagen], die ich hier realisiert habe. Meine docker-compose.yml sieht dann so [[raspi docker-compose.yml]]<nowiki/>aus:

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:

<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen. Ich benutze dazu einen Raspi mit Raspi-OS und GUI. Nachdem man einen externen SD-Card-Reader angeschlossen hat, kann die eingelegte Karte direkt mit einem Befehl der GUI dupliziert werden.

==== Raspi-Alternative x64-ThinClient integrieren [2023] ====
Auf Raspis läuft viele Software, aber keine Programmiersoftware für Simatic S5. Ein Artikel in

[https://www.heise.de/select/ct/2023/6/2301013201757655367 c't 6/2023 S. 34] erläuert eine ausgesuchte kompatible Alternative, die nur wenig mehr elektrische Energie benötigt und eventuell sogar preiswerter ist, einen Thin Client Fujitsu Futro S740. Damit kann die Programmiersoftware für DOS per Dosbox oder für Windows für Wine besser integriert werden, indem sie direkt auf dem FHEM-Server läuft. Folgende Konfigurationsschritte bin ich gegangen:

# LUbuntu LTS vom Stick installieren,
# XRDP nach Anleitung installieren -> Zugriff mit Remmina-Client variable Auflösung,
# [https://wiki.ubuntuusers.de/Wine/ wine] nach Anleitung installieren inklusive Prefix für 32 bit,
# [https://linuxconfig.org/configuring-wine-with-winetricks winetricks] installiert + winetricks corefonts ausgeführt, für passende Schriftarten,
# [https://wiki.winehq.org/Wine_User%27s_Guide#Serial_and_Parallel_Ports wine regedit] benutzt, um COM1 mit /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 zu verbinden,
# Programmiersoftware vom Datenträger installieren,
# Erfolgskontrolle: Programmiersoftware läuft auf FHEM-Server und hat Zugriff auf die S5,
# Docker installieren,
# Docker compose installieren,
# Multicast für SMA-Geräte,
## <code>docker network create -d macvlan -o parent=eno1 --subnet=192.168.1.0/24 --gateway=192.168.1.254 --ip-range=192.168.1.0/27 mymacvlannetwork</code>
## <code><nowiki>https://forum.fhem.de/index.php?topic=114284.0</nowiki></code>
# <code>IPs 192.168.1.1 bis 192.168.1.31 im Router reserviert und vom DHCP ausgeschlossen</code>
#[[futro-docker-compose.yml]] mit für die abweichende Hardware nötigen Änderungen,
#den [https://github.com/klein0r/fhem-style-haus-automatisierung FHEM-Skin entstauben],
#Log-DB neuaufsetzen,
#Umstecken der Programmierleitung zwischen FHEM und PG ist nun nicht mehr nötig. Einfach den Compose-Stack anhalten und es kann direkt losgehen. Bei Problemen hilft eventuell: sudo modprobe -r pl2303 && sudo modprobe pl2303.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, (Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.)

Der Thin Client Fujitsu Futro S740 fühlt sich mit meiner Installation deutlich schneller als ein Raspi4 an.

[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

Raspi docker-compose.yml

2023-04-15T12:44:53Z

Krueuw:

version: '3'
services:
 fhem:
 image: fhem/fhem:latest
 #restart: always
 restart: unless-stopped
 ports:
 - "8083:8083"
 - "7072:7072"
 volumes:
 - ./fhem/core/:/opt/fhem/
 networks:
 default:
 ipv4_address: 192.168.31.1
 devices:
 - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"
 - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"
 - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"
 - "/dev/ttyAMA0:/dev/ttyAMA0"
 environment:
 FHEM_UID: 1000
 FHEM_GID: 1000
 TIMEOUT: 10
 RESTART: 1
 TELNETPORT: 7072
 TZ: Europe/Berlin
 depends_on:
 - "mysql"
 - "mqtt"
 habridge:
 restart: always
 image: habridge/ha-bridge-raspberrypi3
 volumes:
 - ./habridge/data/:/ha-bridge/data
 - /etc/localtime:/etc/localtime:ro
 - /etc/timezone:/etc/timezone:ro
 networks:
 default:
 ipv4_address: 192.168.31.2
# homebridge:
# restart: always
# image: oznu/homebridge:raspberry-pi
# volumes:
# - ./homebridge:/homebridge
# environment:
# - TZ=Europe/Berlin
# - PGID=1000
# - PUID=1000
# - HOMEBRIDGE_CONFIG_UI=1
# - HOMEBRIDGE_CONFIG_UI_PORT=8081
# #network_mode: host
# networks:
# default:
# ipv4_address: 192.168.31.3
# depends_on:
# - "fhem"
 mysql:
 restart: always
 expose:
 - "3306"
 - "33060"
 ports:
 - "3306:3306"
 - "33060:33060"
 image: hypriot/rpi-mysql
 volumes:
 - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
 - ./mysql/data:/var/lib/mysql
 environment:
 - MYSQL_ROOT_PASSWORD=xxx
 - MYSQL_DATABASE=fhem
 - MYSQL_USER=fhemuser
 - MYSQL_PASSWORD=xxx
 networks:
 default:
 ipv4_address: 192.168.31.4
 mqtt:
 restart: always
 expose:
 - "1883"
 - "9001"
 ports:
 - "1883:1883"
 - "9001:9001"
 image: pascaldevink/rpi-mosquitto
 networks:
default:
ipv4_address: 192.168.31.5
 volumes:
 - ./mqtt/config/:/mqtt/config/
 - ./mqtt/log/:/mqtt/log/
 - ./mqtt/data/:/mqtt/data/
 nodered:
 restart: always
 expose:
 - "1880"
 ports:
 - "1880:1880"
 image: elzekool/rpi-nodered
 volumes:
 - ./nodered/data/:/root/.node-red/
 networks:
default:
ipv4_address: 192.168.31.6
 depends_on:
 - "mqtt"
networks:
 default:
 external:
 name: mymacvlannetwork

<code>version: '3'</code>

<code>services:</code>

<code> fhem:</code>

<code> image: fhem/fhem:latest</code>

<code> #restart: always</code>

<code> restart: unless-stopped</code>

<code> ports:</code>

<code> - "8083:8083"</code>

<code> - "7072:7072"</code>

<code> volumes:</code>

<code> - ./fhem/core/:/opt/fhem/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.1</code>

<code> devices:</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> environment:</code>

<code> FHEM_UID: 1000</code>

<code> FHEM_GID: 1000</code>

<code> TIMEOUT: 10</code>

<code> RESTART: 1</code>

<code> TELNETPORT: 7072</code>

<code> TZ: Europe/Berlin</code>

<code> depends_on:</code>

<code> - "mysql"</code>

<code> - "mqtt"</code>

<code> habridge:</code>

<code> restart: always</code>

<code> image: habridge/ha-bridge-raspberrypi3</code>

<code> volumes:</code>

<code> - ./habridge/data/:/ha-bridge/data</code>

<code> - /etc/localtime:/etc/localtime:ro</code>

<code> - /etc/timezone:/etc/timezone:ro</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.2</code>

<code># homebridge:</code>

<code># restart: always</code>

<code># image: oznu/homebridge:raspberry-pi</code>

<code># volumes:</code>

<code># - ./homebridge:/homebridge</code>

<code># environment:</code>

<code># - TZ=Europe/Berlin</code>

<code># - PGID=1000</code>

<code># - PUID=1000</code>

<code># - HOMEBRIDGE_CONFIG_UI=1</code>

<code># - HOMEBRIDGE_CONFIG_UI_PORT=8081</code>

<code># #network_mode: host</code>

<code># networks:</code>

<code># default:</code>

<code># ipv4_address: 192.168.31.3</code>

<code># depends_on:</code>

<code># - "fhem"</code>

<code> mysql:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "3306"</code>

<code> - "33060"</code>

<code> ports:</code>

<code> - "3306:3306"</code>

<code> - "33060:33060"</code>

<code> image: hypriot/rpi-mysql</code>

<code> volumes:</code>

<code> - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql</code>

<code> - ./mysql/data:/var/lib/mysql</code>

<code> environment:</code>

<code> - MYSQL_ROOT_PASSWORD=xxx</code>

<code> - MYSQL_DATABASE=fhem</code>

<code> - MYSQL_USER=fhemuser</code>

<code> - MYSQL_PASSWORD=xxx</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.4</code>

<code> mqtt:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1883"</code>

<code> - "9001"</code>

<code> ports:</code>

<code> - "1883:1883"</code>

<code> - "9001:9001"</code>

<code> image: pascaldevink/rpi-mosquitto</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.5</code>

<code> volumes:</code>

<code> - ./mqtt/config/:/mqtt/config/</code>

<code> - ./mqtt/log/:/mqtt/log/</code>

<code> - ./mqtt/data/:/mqtt/data/</code>

<code> nodered:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1880"</code>

<code> ports:</code>

<code> - "1880:1880"</code>

<code> image: elzekool/rpi-nodered</code>

<code> volumes:</code>

<code> - ./nodered/data/:/root/.node-red/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.6</code>

<code> depends_on:</code>

<code> - "mqtt"</code>

<code>networks:</code>

<code> default:</code>

<code> external:</code>

<code> name: mymacvlannetwork</code>

Raspi docker-compose.yml

2023-04-15T12:44:02Z

Krueuw: Raspi docker-compose.yml

S7 Beispielkonfiguration

2023-04-15T12:35:25Z

Krueuw: /* Raspi-Alternative x64-ThinClient Futro S740 integrieren [2023] */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls Volker Kettenbach hat dafür im [https://forum.fhem.de/index.php?topic=114284.0 Forum eine Lösung vorgeschlagen], die ich hier realisiert habe. Meine docker-compose.yml sieht dann so aus:

<code>version: '3'</code>

<code>services:</code>

<code> fhem:</code>

<code> image: fhem/fhem:latest</code>

<code> #restart: always</code>

<code> restart: unless-stopped</code>

<code> ports:</code>

<code> - "8083:8083"</code>

<code> - "7072:7072"</code>

<code> volumes:</code>

<code> - ./fhem/core/:/opt/fhem/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.1</code>

<code> devices:</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> environment:</code>

<code> FHEM_UID: 1000</code>

<code> FHEM_GID: 1000</code>

<code> TIMEOUT: 10</code>

<code> RESTART: 1</code>

<code> TELNETPORT: 7072</code>

<code> TZ: Europe/Berlin</code>

<code> depends_on:</code>

<code> - "mysql"</code>

<code> - "mqtt"</code>

<code> habridge:</code>

<code> restart: always</code>

<code> image: habridge/ha-bridge-raspberrypi3</code>

<code> volumes:</code>

<code> - ./habridge/data/:/ha-bridge/data</code>

<code> - /etc/localtime:/etc/localtime:ro</code>

<code> - /etc/timezone:/etc/timezone:ro</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.2</code>

<code># homebridge:</code>

<code># restart: always</code>

<code># image: oznu/homebridge:raspberry-pi</code>

<code># volumes:</code>

<code># - ./homebridge:/homebridge</code>

<code># environment:</code>

<code># - TZ=Europe/Berlin</code>

<code># - PGID=1000</code>

<code># - PUID=1000</code>

<code># - HOMEBRIDGE_CONFIG_UI=1</code>

<code># - HOMEBRIDGE_CONFIG_UI_PORT=8081</code>

<code># #network_mode: host</code>

<code># networks:</code>

<code># default:</code>

<code># ipv4_address: 192.168.31.3</code>

<code># depends_on:</code>

<code># - "fhem"</code>

<code> mysql:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "3306"</code>

<code> - "33060"</code>

<code> ports:</code>

<code> - "3306:3306"</code>

<code> - "33060:33060"</code>

<code> image: hypriot/rpi-mysql</code>

<code> volumes:</code>

<code> - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql</code>

<code> - ./mysql/data:/var/lib/mysql</code>

<code> environment:</code>

<code> - MYSQL_ROOT_PASSWORD=xxx</code>

<code> - MYSQL_DATABASE=fhem</code>

<code> - MYSQL_USER=fhemuser</code>

<code> - MYSQL_PASSWORD=xxx</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.4</code>

<code> mqtt:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1883"</code>

<code> - "9001"</code>

<code> ports:</code>

<code> - "1883:1883"</code>

<code> - "9001:9001"</code>

<code> image: pascaldevink/rpi-mosquitto</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.5</code>

<code> volumes:</code>

<code> - ./mqtt/config/:/mqtt/config/</code>

<code> - ./mqtt/log/:/mqtt/log/</code>

<code> - ./mqtt/data/:/mqtt/data/</code>

<code> nodered:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1880"</code>

<code> ports:</code>

<code> - "1880:1880"</code>

<code> image: elzekool/rpi-nodered</code>

<code> volumes:</code>

<code> - ./nodered/data/:/root/.node-red/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.6</code>

<code> depends_on:</code>

<code> - "mqtt"</code>

<code>networks:</code>

<code> default:</code>

<code> external:</code>

<code> name: mymacvlannetwork</code>

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:

<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen. Ich benutze dazu einen Raspi mit Raspi-OS und GUI. Nachdem man einen externen SD-Card-Reader angeschlossen hat, kann die eingelegte Karte direkt mit einem Befehl der GUI dupliziert werden.

==== Raspi-Alternative x64-ThinClient integrieren [2023] ====
Auf Raspis läuft viele Software, aber keine Programmiersoftware für Simatic S5. Ein Artikel in

[https://www.heise.de/select/ct/2023/6/2301013201757655367 c't 6/2023 S. 34] erläuert eine ausgesuchte kompatible Alternative, die nur wenig mehr elektrische Energie benötigt und eventuell sogar preiswerter ist, einen Thin Client Fujitsu Futro S740. Damit kann die Programmiersoftware für DOS per Dosbox oder für Windows für Wine besser integriert werden, indem sie direkt auf dem FHEM-Server läuft. Folgende Konfigurationsschritte bin ich gegangen:

# LUbuntu LTS vom Stick installieren,
# XRDP nach Anleitung installieren -> Zugriff mit Remmina-Client variable Auflösung,
# [https://wiki.ubuntuusers.de/Wine/ wine] nach Anleitung installieren inklusive Prefix für 32 bit,
# [https://linuxconfig.org/configuring-wine-with-winetricks winetricks] installiert + winetricks corefonts ausgeführt, für passende Schriftarten,
# [https://wiki.winehq.org/Wine_User%27s_Guide#Serial_and_Parallel_Ports wine regedit] benutzt, um COM1 mit /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 zu verbinden,
# Programmiersoftware vom Datenträger installieren,
# Erfolgskontrolle: Programmiersoftware läuft auf FHEM-Server und hat Zugriff auf die S5,
# Docker installieren,
# Docker compose installieren,
# Multicast für SMA-Geräte,
## <code>docker network create -d macvlan -o parent=eno1 --subnet=192.168.1.0/24 --gateway=192.168.1.254 --ip-range=192.168.1.0/27 mymacvlannetwork</code>
## <code><nowiki>https://forum.fhem.de/index.php?topic=114284.0</nowiki></code>
# <code>IPs 192.168.1.1 bis 192.168.1.31 im Router reserviert und vom DHCP ausgeschlossen</code>
#[[futro-docker-compose.yml]] mit für die abweichende Hardware nötigen Änderungen,
#den [https://github.com/klein0r/fhem-style-haus-automatisierung FHEM-Skin entstauben],
#Log-DB neuaufsetzen,
#Umstecken der Programmierleitung zwischen FHEM und PG ist nun nicht mehr nötig. Einfach den Compose-Stack anhalten und es kann direkt losgehen. Bei Problemen hilft eventuell: sudo modprobe -r pl2303 && sudo modprobe pl2303.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, (Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.)

Der Thin Client Fujitsu Futro S740 fühlt sich mit meiner Installation deutlich schneller als ein Raspi4 an.

[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2023-04-15T12:19:01Z

Krueuw: /* Raspi-Alternative x64-ThinClient integrieren [2023] */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls Volker Kettenbach hat dafür im [https://forum.fhem.de/index.php?topic=114284.0 Forum eine Lösung vorgeschlagen], die ich hier realisiert habe. Meine docker-compose.yml sieht dann so aus:

<code>version: '3'</code>

<code>services:</code>

<code> fhem:</code>

<code> image: fhem/fhem:latest</code>

<code> #restart: always</code>

<code> restart: unless-stopped</code>

<code> ports:</code>

<code> - "8083:8083"</code>

<code> - "7072:7072"</code>

<code> volumes:</code>

<code> - ./fhem/core/:/opt/fhem/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.1</code>

<code> devices:</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> environment:</code>

<code> FHEM_UID: 1000</code>

<code> FHEM_GID: 1000</code>

<code> TIMEOUT: 10</code>

<code> RESTART: 1</code>

<code> TELNETPORT: 7072</code>

<code> TZ: Europe/Berlin</code>

<code> depends_on:</code>

<code> - "mysql"</code>

<code> - "mqtt"</code>

<code> habridge:</code>

<code> restart: always</code>

<code> image: habridge/ha-bridge-raspberrypi3</code>

<code> volumes:</code>

<code> - ./habridge/data/:/ha-bridge/data</code>

<code> - /etc/localtime:/etc/localtime:ro</code>

<code> - /etc/timezone:/etc/timezone:ro</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.2</code>

<code># homebridge:</code>

<code># restart: always</code>

<code># image: oznu/homebridge:raspberry-pi</code>

<code># volumes:</code>

<code># - ./homebridge:/homebridge</code>

<code># environment:</code>

<code># - TZ=Europe/Berlin</code>

<code># - PGID=1000</code>

<code># - PUID=1000</code>

<code># - HOMEBRIDGE_CONFIG_UI=1</code>

<code># - HOMEBRIDGE_CONFIG_UI_PORT=8081</code>

<code># #network_mode: host</code>

<code># networks:</code>

<code># default:</code>

<code># ipv4_address: 192.168.31.3</code>

<code># depends_on:</code>

<code># - "fhem"</code>

<code> mysql:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "3306"</code>

<code> - "33060"</code>

<code> ports:</code>

<code> - "3306:3306"</code>

<code> - "33060:33060"</code>

<code> image: hypriot/rpi-mysql</code>

<code> volumes:</code>

<code> - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql</code>

<code> - ./mysql/data:/var/lib/mysql</code>

<code> environment:</code>

<code> - MYSQL_ROOT_PASSWORD=xxx</code>

<code> - MYSQL_DATABASE=fhem</code>

<code> - MYSQL_USER=fhemuser</code>

<code> - MYSQL_PASSWORD=xxx</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.4</code>

<code> mqtt:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1883"</code>

<code> - "9001"</code>

<code> ports:</code>

<code> - "1883:1883"</code>

<code> - "9001:9001"</code>

<code> image: pascaldevink/rpi-mosquitto</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.5</code>

<code> volumes:</code>

<code> - ./mqtt/config/:/mqtt/config/</code>

<code> - ./mqtt/log/:/mqtt/log/</code>

<code> - ./mqtt/data/:/mqtt/data/</code>

<code> nodered:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1880"</code>

<code> ports:</code>

<code> - "1880:1880"</code>

<code> image: elzekool/rpi-nodered</code>

<code> volumes:</code>

<code> - ./nodered/data/:/root/.node-red/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.6</code>

<code> depends_on:</code>

<code> - "mqtt"</code>

<code>networks:</code>

<code> default:</code>

<code> external:</code>

<code> name: mymacvlannetwork</code>

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:

<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen. Ich benutze dazu einen Raspi mit Raspi-OS und GUI. Nachdem man einen externen SD-Card-Reader angeschlossen hat, kann die eingelegte Karte direkt mit einem Befehl der GUI dupliziert werden.

==== Raspi-Alternative x64-ThinClient integrieren [2023] ====
Auf Raspis läuft viele Software, aber keine Programmiersoftware für Simatic S5. Ein Artikel in

[https://www.heise.de/select/ct/2023/6/2301013201757655367 c't 6/2023 S. 34] erläuert eine ausgesuchte kompatible Alternative, die nur wenig mehr elektrische Energie benötigt und eventuell sogar preiswerter ist, einen Thin Client Fujitsu Futro S740. Damit kann die Programmiersoftware für DOS per Dosbox oder für Windows für Wine besser integriert werden, indem sie direkt auf dem FHEM-Server läuft. Folgende Konfigurationsschritte bin ich gegangen:

# LUbuntu LTS vom Stick installieren,
# XRDP nach Anleitung installieren -> Zugriff mit Remmina-Client variable Auflösung,
# wine nach Anleitung installieren <nowiki>https://wiki.ubuntuusers.de/Wine/</nowiki> inklusive Prefix für 32 bit,
# [https://linuxconfig.org/configuring-wine-with-winetricks winetricks] installiert + winetricks corefonts ausgeführt, für passende Schriftarten,
# [https://wiki.winehq.org/Wine_User%27s_Guide#Serial_and_Parallel_Ports wine regedit] benutzt, um COM1 mit /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 zu verbinden
# Programmiersoftware vom Datenträger installieren
# Erfolgskontrolle: Programmiersoftware läuft auf FHEM-Server und hat Zugriff auf die S5
# Docker installieren
# Docker compose installieren
# <code>docker network create -d macvlan -o parent=eno1 --subnet=192.168.1.0/24 --gateway=192.168.1.254 --ip-range=192.168.1.0/27 mymacvlannetwork</code>
# <code><nowiki>https://forum.fhem.de/index.php?topic=114284.0</nowiki></code>
# <code>IPs im Router reserviert und vom DHCP ausgeschlossen</code>
#[[futro-docker-compose.yml]]

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

Futro-docker-compose.yml

2023-04-15T12:18:09Z

Krueuw: FHEM + Multicast + ttyUSB docker-compose.yml

version: '2'

services:
fhem:
restart: always
ports:
- "8083:8083"
- "7072:7072"
image: fhem/fhem:latest
volumes:
- ./fhem/core/:/opt/fhem/
networks:
default:
ipv4_address: 192.168.29.1
devices:
# - "/dev/ttyUSB0:/dev/ttyUSB0"
- "/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0:/dev/ttyS5"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"
- "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"
environment:
FHEM_UID: 1000
FHEM_GID: 1000
TIMEOUT: 10
RESTART: 1
TELNETPORT: 7072
TZ: Europe/Berlin
depends_on:
- "mysql"
- "mqtt"

mysql:
restart: always
expose:
- "3306"
- "33060"
ports:
- "3306:3306"
- "33060:33060"
image: mysql/mysql-server:5.7
volumes:
- ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
- ./mysql/data:/var/lib/mysql
environment:
- MYSQL_DATABASE=fhem
- MYSQL_USER=fhemuser
- MYSQL_PASSWORD=2jRHkcdw3WuNSQAcX7
- MYSQL_ROOT_PASSWORD=KQW8jcxkjr4CpSMaz
- MYSQL_RANDOM_ROOT_PASSWORD=false
- MYSQL_ONETIME_PASSWORD=false
networks:
default:
ipv4_address: 192.168.1.4

mqtt:
restart: always
expose:
- "1883"
- "9001"
ports:
- "1883:1883"
- "9001:9001"
image: eclipse-mosquitto:2.0.15
networks:
default:
ipv4_address: 192.168.1.5
volumes:
- ./mqtt/config/:/mosquitto/config/
- ./mqtt/log/:/mosquitto/log/
- ./mqtt/data/:/mosquitto/data/
networks:
default:
external:
name: mymacvlannetwork

S7 Beispielkonfiguration

2023-04-15T12:07:45Z

Krueuw: X64 kompatible Hardware ersetzt Raspi

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls Volker Kettenbach hat dafür im [https://forum.fhem.de/index.php?topic=114284.0 Forum eine Lösung vorgeschlagen], die ich hier realisiert habe. Meine docker-compose.yml sieht dann so aus:

<code>version: '3'</code>

<code>services:</code>

<code> fhem:</code>

<code> image: fhem/fhem:latest</code>

<code> #restart: always</code>

<code> restart: unless-stopped</code>

<code> ports:</code>

<code> - "8083:8083"</code>

<code> - "7072:7072"</code>

<code> volumes:</code>

<code> - ./fhem/core/:/opt/fhem/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.1</code>

<code> devices:</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> environment:</code>

<code> FHEM_UID: 1000</code>

<code> FHEM_GID: 1000</code>

<code> TIMEOUT: 10</code>

<code> RESTART: 1</code>

<code> TELNETPORT: 7072</code>

<code> TZ: Europe/Berlin</code>

<code> depends_on:</code>

<code> - "mysql"</code>

<code> - "mqtt"</code>

<code> habridge:</code>

<code> restart: always</code>

<code> image: habridge/ha-bridge-raspberrypi3</code>

<code> volumes:</code>

<code> - ./habridge/data/:/ha-bridge/data</code>

<code> - /etc/localtime:/etc/localtime:ro</code>

<code> - /etc/timezone:/etc/timezone:ro</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.2</code>

<code># homebridge:</code>

<code># restart: always</code>

<code># image: oznu/homebridge:raspberry-pi</code>

<code># volumes:</code>

<code># - ./homebridge:/homebridge</code>

<code># environment:</code>

<code># - TZ=Europe/Berlin</code>

<code># - PGID=1000</code>

<code># - PUID=1000</code>

<code># - HOMEBRIDGE_CONFIG_UI=1</code>

<code># - HOMEBRIDGE_CONFIG_UI_PORT=8081</code>

<code># #network_mode: host</code>

<code># networks:</code>

<code># default:</code>

<code># ipv4_address: 192.168.31.3</code>

<code># depends_on:</code>

<code># - "fhem"</code>

<code> mysql:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "3306"</code>

<code> - "33060"</code>

<code> ports:</code>

<code> - "3306:3306"</code>

<code> - "33060:33060"</code>

<code> image: hypriot/rpi-mysql</code>

<code> volumes:</code>

<code> - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql</code>

<code> - ./mysql/data:/var/lib/mysql</code>

<code> environment:</code>

<code> - MYSQL_ROOT_PASSWORD=xxx</code>

<code> - MYSQL_DATABASE=fhem</code>

<code> - MYSQL_USER=fhemuser</code>

<code> - MYSQL_PASSWORD=xxx</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.4</code>

<code> mqtt:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1883"</code>

<code> - "9001"</code>

<code> ports:</code>

<code> - "1883:1883"</code>

<code> - "9001:9001"</code>

<code> image: pascaldevink/rpi-mosquitto</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.5</code>

<code> volumes:</code>

<code> - ./mqtt/config/:/mqtt/config/</code>

<code> - ./mqtt/log/:/mqtt/log/</code>

<code> - ./mqtt/data/:/mqtt/data/</code>

<code> nodered:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1880"</code>

<code> ports:</code>

<code> - "1880:1880"</code>

<code> image: elzekool/rpi-nodered</code>

<code> volumes:</code>

<code> - ./nodered/data/:/root/.node-red/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.6</code>

<code> depends_on:</code>

<code> - "mqtt"</code>

<code>networks:</code>

<code> default:</code>

<code> external:</code>

<code> name: mymacvlannetwork</code>

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:

<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen. Ich benutze dazu einen Raspi mit Raspi-OS und GUI. Nachdem man einen externen SD-Card-Reader angeschlossen hat, kann die eingelegte Karte direkt mit einem Befehl der GUI dupliziert werden.

==== Raspi-Alternative x64-ThinClient integrieren [2023] ====
Auf Raspis läuft viele Software, aber keine Programmiersoftware für Simatic S5. Ein Artikel in

[https://www.heise.de/select/ct/2023/6/2301013201757655367 c't 6/2023 S. 34] erläuert eine ausgesuchte kompatible Alternative, die nur wenig mehr elektrische Energie benötigt und eventuell sogar preiswerter ist, einen Thin Client Fujitsu Futro S740. Damit kann die Programmiersoftware für DOS per Dosbox oder für Windows für Wine besser integriert werden, indem sie direkt auf dem FHEM-Server läuft. Folgende Konfigurationsschritte bin ich gegangen:

# LUbuntu LTS vom Stick installieren,
# XRDP nach Anleitung installieren -> Zugriff mit Remmina-Client variable Auflösung,
# wine nach Anleitung installieren <nowiki>https://wiki.ubuntuusers.de/Wine/</nowiki> inklusive Prefix für 32 bit,
# [https://linuxconfig.org/configuring-wine-with-winetricks winetricks] installiert + winetricks corefonts ausgeführt, für passende Schriftarten,
# wine regedit benutzt, um COM1 mit /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 zu verbinden
# Programmiersoftware vom Datenträger installieren
# Erfolgskontrolle: Programmiersoftware läuft auf FHEM-Server und hat Zugriff auf die S5
# Docker installieren
# Docker compose installieren
# <code>docker network create -d macvlan -o parent=eno1 --subnet=192.168.29.0/24 --gateway=192.168.29.254 --ip-range=192.168.29.0/27 mymacvlannetwork</code>
# <code><nowiki>https://forum.fhem.de/index.php?topic=114284.0</nowiki></code>
# <code>IPs im Router reserviert und vom DHCP ausgeschlossen</code>
#

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2023-03-31T10:10:36Z

Krueuw: /* Alte Konfiguration in den neuen Container übernehmen */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls Volker Kettenbach hat dafür im [https://forum.fhem.de/index.php?topic=114284.0 Forum eine Lösung vorgeschlagen], die ich hier realisiert habe. Meine docker-compose.yml sieht dann so aus:

<code>version: '3'</code>

<code>services:</code>

<code> fhem:</code>

<code> image: fhem/fhem:latest</code>

<code> #restart: always</code>

<code> restart: unless-stopped</code>

<code> ports:</code>

<code> - "8083:8083"</code>

<code> - "7072:7072"</code>

<code> volumes:</code>

<code> - ./fhem/core/:/opt/fhem/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.1</code>

<code> devices:</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> environment:</code>

<code> FHEM_UID: 1000</code>

<code> FHEM_GID: 1000</code>

<code> TIMEOUT: 10</code>

<code> RESTART: 1</code>

<code> TELNETPORT: 7072</code>

<code> TZ: Europe/Berlin</code>

<code> depends_on:</code>

<code> - "mysql"</code>

<code> - "mqtt"</code>

<code> habridge:</code>

<code> restart: always</code>

<code> image: habridge/ha-bridge-raspberrypi3</code>

<code> volumes:</code>

<code> - ./habridge/data/:/ha-bridge/data</code>

<code> - /etc/localtime:/etc/localtime:ro</code>

<code> - /etc/timezone:/etc/timezone:ro</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.2</code>

<code># homebridge:</code>

<code># restart: always</code>

<code># image: oznu/homebridge:raspberry-pi</code>

<code># volumes:</code>

<code># - ./homebridge:/homebridge</code>

<code># environment:</code>

<code># - TZ=Europe/Berlin</code>

<code># - PGID=1000</code>

<code># - PUID=1000</code>

<code># - HOMEBRIDGE_CONFIG_UI=1</code>

<code># - HOMEBRIDGE_CONFIG_UI_PORT=8081</code>

<code># #network_mode: host</code>

<code># networks:</code>

<code># default:</code>

<code># ipv4_address: 192.168.31.3</code>

<code># depends_on:</code>

<code># - "fhem"</code>

<code> mysql:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "3306"</code>

<code> - "33060"</code>

<code> ports:</code>

<code> - "3306:3306"</code>

<code> - "33060:33060"</code>

<code> image: hypriot/rpi-mysql</code>

<code> volumes:</code>

<code> - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql</code>

<code> - ./mysql/data:/var/lib/mysql</code>

<code> environment:</code>

<code> - MYSQL_ROOT_PASSWORD=xxx</code>

<code> - MYSQL_DATABASE=fhem</code>

<code> - MYSQL_USER=fhemuser</code>

<code> - MYSQL_PASSWORD=xxx</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.4</code>

<code> mqtt:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1883"</code>

<code> - "9001"</code>

<code> ports:</code>

<code> - "1883:1883"</code>

<code> - "9001:9001"</code>

<code> image: pascaldevink/rpi-mosquitto</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.5</code>

<code> volumes:</code>

<code> - ./mqtt/config/:/mqtt/config/</code>

<code> - ./mqtt/log/:/mqtt/log/</code>

<code> - ./mqtt/data/:/mqtt/data/</code>

<code> nodered:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1880"</code>

<code> ports:</code>

<code> - "1880:1880"</code>

<code> image: elzekool/rpi-nodered</code>

<code> volumes:</code>

<code> - ./nodered/data/:/root/.node-red/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.6</code>

<code> depends_on:</code>

<code> - "mqtt"</code>

<code>networks:</code>

<code> default:</code>

<code> external:</code>

<code> name: mymacvlannetwork</code>

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:

<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen. Ich benutze dazu einen Raspi mit Raspi-OS und GUI. Nachdem man einen externen SD-Card-Reader angeschlossen hat, kann die eingelegte Karte direkt mit einem Befehl der GUI dupliziert werden.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

MQTT GENERIC BRIDGE

2022-05-31T14:59:38Z

Krueuw: /* Einführung */

{{Infobox Modul
|ModPurpose=Stellt für beliebige Geräte eine Schnittstellt zum MQTT-Protokoll zur Verfügung
|ModType=d
|ModCmdRef=MQTT_GENERIC_BRIDGE
|ModForumArea=MQTT
|ModTechName=10_MQTT_GENERIC_BRIDGE.pm
|ModOwner=hexenmeister ({{Link2FU|4065|Forum}}) }}

{{Baustelle}}

==Einführung==

Das Modul ''MQTT_GENERIC_BRIDGE'' stellt eine zentrale Schnittstelle zum MQTT-Protokoll für beliebig viele andere FHEM-Geräte bereit. Es wird für eine FHEM-Installation jeweils nur ein erreichbarer MQTT-Server sowie eine Instanz der ''MQTT_GENERIC_BRIDGE'' benötigt. Es ist aber auch möglich, mehrere Server parallel zu betreiben.

Dieses Modul kann seit November 2018 mit allen drei IO-Modul-Varianten zusammen eingesetzt werden, also sowohl mit {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} bzw. [[MQTT2_CLIENT]] oder [[MQTT (Modul)|MQTT]](00_MQTT.pm), und seit Rev. 23514 (Jan. 2021) wird für ''MQTT_GENERIC_BRIDGE'' iVm. den MQTT2-IO-Modulen keine zusätzliche Software mehr benötigt.

Dabei erfolgt an dem zentralen ''MQTT_GENERIC_BRIDGE''-Gerät selbst nur eine Basiskonfiguration, die Standardwerte für alle anzubindenden Geräte bereitstellt, alle übrigen Einstellungen erfolgen durch Attribute an dem jeweiligs anzubindenden Gerät selbst.

Beispiel: ein Aktor des Typs [[HomeMatic|CUL_HM]] kann über MQTT-Kommandos an den für ihn passenden Topic an- oder ausgeschaltet werden oder auch einfach nur seinen aktuellen Schaltzustand per MQTT-Protokoll publizieren.

==Installation==
===Vorbereitung===
Im folgenden wird als MQTT-Server ''mosquitto'' verwendet, der in aktuellen Linux-Distributionen über die Paketverwaltung angeboten wird. Hier die Installation für Raspberry Pi OS:
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install mosquitto

Es kann aber auch ein bereits vorhandener {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} verwendet werden.

===Grundsätzliche Konfiguration===
Definition der Schnittstelle zum MQTT-Server (hier: auf demselben Raspberry):

defmod mqtt_io MQTT2_CLIENT 127.0.0.1:1883
attr mqtt_io alias MQTT Broker
attr mqtt_io devStateIcon .*active:none:disconnect .*disconnected:none:connect
attr mqtt_io group MQTT
attr mqtt_io icon mqtt
attr mqtt_io room IO_Devices

Wer möchte, kann den Status des FHEM-Servers per MQTT LWT mitteilen:

Für MQTT2_CLIENT:
attr mqtt_io lwt system/<fhem-name>/connection/status connection lost
attr mqtt_io lwtRetain 1
attr mqtt_io msgAfterConnect -r system/<fhem-name>/connection/status connected
attr mqtt_io msgBeforeDisconnect -r system/<fhem-name>/connection/status disconnected

Alternativ: für [[MQTT (Modul)|MQTT]]
attr mqtt last-will retain:1 system/<fhem-name>/connection/status connection lost
attr mqtt on-connect retain:1 {Log3("mqtt",3,"connected to MQTT server");;1} system/<fhem-name>/connection/status connected
attr mqtt on-disconnect retain:1 {Log3("mqtt",3,"disconnected from MQTT server");;1} system/<fhem-name>/connection/status disconnected

===Definition der Generic Bridge===
Der Name ''mqttGenericBridge'' kann dabei frei gewählt werden:
defmod mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev mqtt_io
attr mqttGenericBridge alias MQTT generic bridge
attr mqttGenericBridge group MQTT
attr mqttGenericBridge room IO_Devices
attr mqttGenericBridge stateFormat dev: device-count in: incoming-count out: outgoing-count

Damit sind die wesentlichen Vorarbeiten abgeschlossen, und die ''MQTT_GENERIC_BRIDGE'' kann bereits dafür genutzt werden, beliebige Reading- oder Attribut-Änderungen von FHEM-Devices über MQTT zu publishen oder entsprechende Anweisungen umzusetzen. Es wird jedoch empfohlen, zunächst noch einige grundlegende Einstellungen vorzunehmen. Hierfür - sowie dann auch für die Konfiguration der weiteren Devices, die an MQTT angebunden werden sollen, steht als Hilfsmittel [[attrTemplate]] zur Verfügung.

===Basisangaben in der MQTT_GENERIC_BRIDGE selbst===
[[Datei:MGB attrTemplate Base.PNG|400px|thumb|attrTemplate base_settings_to_MQTT_GENERIC_BRIDGE]]Zunächst werden die Basisangaben zur Struktur der zu verwendenden MQTT-Topics sowie - bei Verwendung eines MQTT2-Interface-Moduls - die ''clientOrder'' konfiguriert:
set mqttGenericBridge attrTemplate base_settings_to_MQTT_GENERIC_BRIDGE
Dies kann direkt über die Detailansicht des Geräts mqttGenericBridge erfolgen, siehe der nebenstehende screenshot, aus dem auch zu entnehmen ist, was das attrTemplate an Änderungen der Konfiguration vornehmen wird. Dies sind zwei Aspekte:
Zum einen wird eine Variable namens $base in Sende- und in Empfangsrichtung festgelegt. In Senderichtung (pub:) besteht diese nur aus dem Namen der ''MQTT_GENERIC_BRIDGE'', in Empfangsrichtung (sub:) aus dem Namen sowie dem Topic-Anteil ''set''. Diese Angaben können im Prinzip beliebig geändert werden, es muss lediglich darauf geachtet werden, dass die Angaben unterschiedlich sind, sonst kann es zu unbeabsichtigten Schleifen kommen!
[[Datei:MGB attrTemplate Base M2IO options.PNG|400px|thumb|attrTemplate Anfrage der gewünschten Konfigurationsoption]]Zum anderen wird - sofern ein ''MQTT2_CLIENT'' und ''MQTT2_SERVER'' als Interface verwendet wird - je nach Wahl des Nutzers in dem dann erscheinenden Dialogfeld - die clientOrder festgelegt. Wer hier unschlüssig ist, sollte die empfohlene Variante wählen, um Probleme im Zusammenspiel mit der ''autocreate''-Funktion dieser Interface-Typen möglichst zu vermeiden.

{{Hinweis|In vielen [[Dokumentationsstruktur#Internet, Blogs usw.|im Internet zu findenden Anleitungen]] wird pauschal das Attribut ''globalPublish'' gesetzt. Dieses führt allerdings dazu, dass zum einen sehr viele unwichtige Daten (oder eben ggf. auch unbeabsichtigt: eigentlich besser geheim zu haltende Daten?) an den MQTT-Server übermittelt werden, und zum anderen eine aufwändige Nachbearbeitung auf der Gegenseite erforderlich werden kann. Daher wird hiervon '''ausdrücklich abgeraten!''' Stattdessen kann man relativ einfach über den attrTemplate-Mechanismus (nur) die Informationen über MQTT verfügbar machen, die in der Regel für externe Anwendungen auch benötigt werden.}}

==Basics zur Konfiguration der anzubindenden Geräte==
{{Randnotiz|RNTyp=g|RNText=Auch wer plant, später die Kommandos mit einer ganz anderen Software zu versenden, sollte zunächst den Weg über die Linux-Konsole und die Tools ''mosquitto_sub'' und ''mosquitto_pub'' gehen. So läßt sich die Funktionalität von FHEM und der MQTT_GENERIC_BRIDGE zunächst ohne weitere Störeinflüsse prüfen und andere User können leichter helfen, falls Probleme auftreten sollten.}}
Um gezielt einzelne Werte zu senden und auch nur gewünschte Anweisungen zu erhalten, ist stattdessen eine auf das jeweilige Gerät angepasste Konfiguration der Schnittstelle zu empfehlen. Um die hier dargestellten Schritte und deren Wirksamkeit zu prüfen, sollte der Verkehr von und zum MQTT-Server beobachtet werden. Im Folgenden werden hierfür die Programme ''mosquitto_sub'' und ''mosquitto_pub'' aus dem Paket ''mosquitto-clients'' verwendet. Auf einem ''Raspberry Pi OS'' können diese mit <code>sudo apt-get install mosquitto-clients</code> installiert werden. Beide Programme funktionieren auch mit einem MQTT2_SERVER.

Den Verkehr auf der Linux-Konsole kann man mit
mosquitto_sub -h 127.0.0.1 -i fhem-test -v -t mqttGenericBridge/# -t system/#
verfolgen, gegebenenfalls sind Username und Passwort zu ergänzen, falls die Einstellungen am Server dies erfordern (siehe ''manpage'' zu ''mosquitto_sub'').

===Readingwerte publishen===
====mqttPublish====
{{Randnotiz|RNTyp=y|RNText=Der Name der Attribute kann abweichen, falls ein anderes ''MQTT-Präfix'' über das ''Define'' in der ''MQTT_GENERIC_BRIDGE'' gesetzt ist. Hier wird davon ausgegangen, dass dieses nicht geändert wurde.}}

Um Reading-Werte von einem Gerät zu versenden, wird das Attribut ''mqttPublish'' verwendet. Im einfachsten Fall wird festgelegt, welche Readings versendet werden sollen, und unter welchem Topic. Für einen beliebigen Temperatursensor könnte dies z.B. so aussehen:
attr mySensor mqttPublish temperature:topic={"$base/$device/$name"}
In der Linux.Konsole, in der ''mosquitto_sub'' läuft, sollte jetzt bei jeder Aktualisierung des Sensor-Werts anzeigen, dass eine entsprechende Message an den MQTT-Server gesendet wurde. Dies geschieht [[Event|Event-basiert]], so dass sich hier ggf. auch insbesondere Einstellungen im Attribut [[Event-on-change-reading|event-on-change-reading]] auf die Häufigkeit der Aktualisierung auswirken.

Es können auch mehrere Readings erfasst werden, für einen typischen kombinierten Temperatur- und Luftfeuchtigkeitssensor könnte dies z.B. so aussehen:
attr mySensor mqttPublish temperature|humidity:topic={"$base/$device/$name"}
oder auch so:
attr mySensor mqttPublish temperature|humidity|battery:topic={"$base/$device/$name"}

Falls (!) erforderlich oder gewünscht, kann auch ein ''*'' als ''wildcard'' verwendet werden. Dann werden alle Readings gepublisht:
attr mySensor mqttPublish *:topic={"$base/$device/$name"}

====mqttAlias====
Verfolgt man den Verkehr eine Zeitlang, wird die Bedeutung der Variablen klarer: ''$base'' entspricht der Angabe aus den ''globalDefaults'' an der ''MQTT_GENERIC_BRIDGE'', ''$device'' wird durch den Namen des Geräts in FHEM erstetzt, und ''$name'' entspricht (noch) dem Namen des Readings.
Bis hierhin könnte man also auch statt einer MQTTT_GENERIC_BRIDGE problemlos ein [[notify]] verwenden, um die Events für direkte publish-Anweisungen am jeweiligen Interface-Modul (z.B. MQTT2_CLIENT) auszuwerten.

Eine ''MQTT_GENERIC_BRIDGE'' bietet jedoch auch für das Publishen erweiterte Funktionalitäten an. Die erste: Z.B. kann der Parameter ''$name'' - etwa zur [[DevelopmentGuidelinesReadings|Standardisierung der Namensstruktur der Readings]] - mit Hilfe des Attributs ''mqttAlias'' verändert werden. Durch die folgende Einstellung würde z.B. ein ''battery''-Wert unter dem Topic-Teil ''batteryPercent'' versendet und das Reading ''measured-temp'' unter ''temperature'':
attr mySensor mqttAlias battery=batteryPercent measured-temp=temperature

====state====
Da das Reading ''state'' in FHEM in der Regel eine Art Hauptzustand eines Geräts beschreibt, wird für die weiter unten dargestellten ''attrTemplate'' dieses Reading kein ''$name''-Anteil im Topic versendet. Ein einfaches "ein-aus"-Gerät kann man dieser Vorgabe folgend daher so konfigurieren:
attr myRelay mqttPublish state:topic={"$base/$device"}

Für ein dimmbares Licht (das als Reading ''pct'' kennt) kombiniert man beides:
attr myDimmer mqttPublish state:topic={"$base/$device"} pct:topic={"$base/$device/$name"}

Und zu guter letzt noch als farbiges (mit Reading ''rgb'') und dimmbares Licht:
attr myRGBLight mqttPublish state:topic={"$base/$device"} pct|rgb:topic={"$base/$device/$name"}

===Geräte steuern===
{{Randnotiz|RNTyp=y|RNText=Kommt als MQTT-Server MQTT2_SERVER zum Einsatz, ist zwingend eine ''ClientID'' mit anzugeben, andernfalls werden die so generierten Messages eventuell nicht ausgewertet!}}Um Geräte über die MQTT-Schnittstelle bedienen zu können, wird zum einen eine Software benötigt, mit der man entsprechende publish-Anweisungen generieren kann. Dies kann z.B. das bereits genannte ''mosquitto_pub'' sein.
====mqttSubscribe====
Spiegelbildlich zum o.g. ''mqttPublish''-Attribut wird über das jeweilige ''mqttSubscribe''-Attribut festgelegt, welche Topics für das FHEM-Gerät ausgewertet werden sollen und welchen Readings diese zugeordnet sind.
Für ein einfaches "ein-aus"-Gerät verwendet man daher denselben Attributwert wie für das ''mqttPublish'':
attr myRelay mqttSubscribe state:stopic={"$base/$device"}

Da wir oben in ''globalDefaults'' für ''sub:$base=mqttGenericBridge/set'' festgelegt haben, muss die Schaltanweisung allerdings an einen anderen Topic erfolgen als die Statusmeldung, die wir wegen des ''mqttPublish''-Attributs erhalten - auf diese Weise können unbeabsichtigte Schleifen unterbunden werden.

Um jetzt mit ''mosquitto_pub'' eine passende Anweisung zu erzeugen, benötigen wir eine weitere (ssh-Linux-) Konsole, über die wir dann auf dem MQTT-Weg schalten können - vorausgesetzt, das Gerät ''myRelay'' kann den Befehl <code>set myRelay on</code> (bzw. ''off'') verarbeiten. Auch hier wären ggf. die Zugangsdaten entsprechend der ''manpage'' zu ergänzen:
mosquitto_pub -h 127.0.0.1 -i fhem-test -t mqttGenericBridge/set/myRelay -m on

Bei ''mosquitto_sub'' auf der Linux-Konsole sollte jetzt zunächst die Schaltanweisung (Topic mit ''set-Element'') wie auch die Readingänderung am Device vermeldet werden.

====Geräte mit mehreren Settern====
Das Prinzip dürfte jetzt klarer sein, also versuchen wir es direkt mit unserer farbigen Leuchte:
attr myRGBLight mqttSubscribe state:stopic={"$base/$device"} pct|rgb:stopic={"$base/$device/$name"}
Und schon sollte diese über ''msoquitto_pub'' bzw. MQTT schalt- und dimmbar sein und Farbänderungen entegennehmen - und natürlich den zugehörigen Status zurückmelden.

====mqttAlias====
Auch bei den Supscriptions besteht die Möglichkeit, ''mqttAlias'' zu verwenden und die Namen über diesen Weg zu verändern. Dies kann insbesondere sinnvoll sein, um in externen Anwendungen dann (dort) dieselben Vorlagen nutzen zu können.

====topic, stopic und atopic====
In obigem Beispiel haben wir in ''mqttSubscribe'' das Schlüsselwort ''stopic'' (die Kurzform von ''set-topic'') verwendet. Dieses bewirkt bei einer entsprechenden MQTT-Nachricht dasselbe wie der FHEM-Befehl <code>set <device> <reading> <value></code>, also <code>set myRGBLight pct 70</code>. Daneben gibt es die weiteren Schlüsselwörter ''topic'' und ''atopic''.
* ''topic'' (Langform: readings-topic) entspicht einer ''setreading''-Anweisung. Dabei wird dann lediglich der Readingwert aktualisiert, allerdings (falls Hardware gesteuert werden könnte) aber kein Schaltbefehl an die Hardware gesendet. In Installationen ohne MQTT2-Interface kann dies dazu genutzt werden, [[Dummy|dummy]]-Geräte ähnlich flexibel zu verwenden wie [[MQTT2_DEVICE]].
* ''atopic'' (Langform: attr-topic) schließlich dient dazu, Attributwerte zu ändern. ''atopic'' kann auch in ''mqttPublish'' eingesetzt werden, um Änderungen der Attribut-Werte an den MQTT-Server zu übermitteln.

===Weitere Optionen===
''MQTT_GENERIC_BRIDGE'' bietet weitere Attribute, die im Zusammenspiel teils sehr umfassende weitere Möglichkeiten ergeben, Geräte an MQTT anzubinden. Einige der Möglichkeiten, insbesondere, über ''expression'' beliebigen Perl-Code zur Auswertung bzw. Strukturierung der Daten zu verwenden, sind in den Grundzügen weiter unten dargestellt.

==Standardisierung via attrTemplate==
Insbesondere zur Anbindung externer Lösungen ist es jedoch häufig ausreichend, die Geräte-Daten in einer etwas strukturierten Weise aufzubereiten. Dies ist das Ziel der für ''MQTT_GENERIC_BRIDGE'' entwickelten ''attrTemplate''.

(tbc)

==Konfigurationsmöglichkeiten für Fortgeschrittene==

===expression===

attr ZWave_THERMOSTAT_20 mqttGB1Alias reportedState=actuator
attr ZWave_THERMOSTAT_20 mqttGB1Publish desired-temp|temperature|reportedState:topic={"$base/$device/$name"} temperature:expression={$value=~m,(-?\d+(\.\d+)?),?::round($1,1):undef} reportedState:expression={$value=~m,dim.(\d+),?$1:undef}
attr ZWave_THERMOSTAT_20 mqttGB1Subscribe desired-temp:stopic={"$base/$device/$name"}

===JSON===
json2nameValue() und toJSON() via expression

===publishes an mehrere Topics===
"das Ausrufezeichen"

(Noch nachzubearbeiten, aus dem Thread Anwendungsfälle und Beispiele für MQTT_GENERIC_BRIDGE - https://forum.fhem.de/index.php/topic,91642.msg841367.html#msg841367)
-----

eine Reading an einem beliebigen Device per MQTT setzen (für State-Reading soll state verwendet werden)
Code: [Auswählen]

attr <device-name> mqttSubscribe <reading-name>:topic=<topic>

(anstatt 'topic' kann für eine bessere Lesbarkeit 'readings-topic' verwendet werden)

ein Set-Befehl an einem beliebigen Device mit dem per MQTT gesendeten Wert ausführen
(für set ohne namen (set on, set off) soll state verwendet werden)
Code: [Auswählen]

attr <device-name> mqttSubscribe <set-befehl>:stopic=<topic>

(anstatt 'stopic' kann für eine bessere Lesbarkeit 'set-topic' verwendet werden)

ein Attribut an einem beliebigen Device per MQTT setzen
Code: [Auswählen]

attr <device-name> mqttSubscribe <attribut-name>:atopic=<topic>

(anstatt 'atopic' kann für eine bessere Lesbarkeit 'attr-topic' verwendet werden)

eine Änderung eines Readings per MQTT senen
Code: [Auswählen]

attr <device-name> mqttPublish <readings-name>:topic=<topic>

eine Änderung eines Attributes per MQTT senen
attr <device-name> mqttPublish <attribut-name>:atopic=<topic>

Verwendung von Variablen
Es können mit dem Attribute mqttDefaults Variablen definiert werden, die in mqttPublish und mqttSubscribe verwendet werden können:
Code: [Auswählen]

attr <device-name> mqttDefaults base={"allgemeinerPfad/"}
...
attr <device-name> mqttPublish <reading-name>:topic={"$base/irgendEinName"}

Weiterhin können in Topics folgende vordefinierte Variablen verwendet werden:
$reading - aktuell zu verarbeitende Reading
$device - aktulles Gerät
$name - Die Variable $name wird im Unterschied zu $reading ggf. ueber die in 'mqttAlias' definierten Aliases beeinflusst. (s. Commandref für mqttAlias)
Code: [Auswählen]

attr <device-name> mqttPublish <reading-name>:topic={"$base/$device/$name"}

Mehrere Readings auf einmal
Es können für einen Topic (sinnigerweise mit Variablen) auch mehrere Readings gleichzeitig angegeben werden. Diese müssen in diesem Fall durch ein | getrennt werden:
Code: [Auswählen]

attr <device-name> mqttPublish <reading-name1>|<reading-name2>:topic={"$base/$device/$name"}

Wildcards
mit einem * kann ein Topic für alle Readings zusammen definiert werden:
Code: [Auswählen]

attr <device-name> mqttPublish *:topic={"$base/$device/$name"}

Beim Subscribe können in der Topic-Definition auch MQTT-Wildcards (+ und #) verwendet werden.
Falls der Reading-Name mit einem '*'-Zeichen am Anfang definiert wird, gilt dieser als 'Platzhalter'. Der tatsaechliche Name der Reading (und ggf. des Geraetes) wird dabei durch Variablen aus dem Topic definiert ($reading, $name). Im Topic wirken diese Variablen als Wildcards, macht natuerlich nur Sinn, wenn Reading-Name auch nicht fest definiert ist (also faengt mit '*' an).

-----------------

Sensoren-Werte von einer FHEM-Instanz in eine andere übertragen

Definition für ein HomeMatic-Device (Dirk's-Sensor + Verwendung von DevPoint-Modul):
(es werden gezielt bestimmte Werte übertragen)
Code: [Auswählen]

defmod <sensor-device-name> CUL_HM xxxxxx
attr <sensor-device-name> model HB-UW-Sen-THPL-I
...
attr <sensor-device-name> mqttDefaults base=haus/wohnzimmer
attr <sensor-device-name> mqttPublish humidity|luminosity|dewpoint|absoluteHumidity:topic={"$base/klima/$name"}

Definition eines Empfänger-Dummy:
(es werden alle Werte bei passenden Topics empfangen)
Code: [Auswählen]

defmod <dummy-device-name> dummy
attr <dummy-device-name> readingList absoluteHumidity dewpoint humidity luminosity temperature vapourPressure
attr <dummy-device-name> mqttDefaults base=haus/wohnzimmer
attr <dummy-device-name> mqttSubscribe *:topic={"$base/klima/$reading"}

« Letzte Änderung: 11 Januar 2019, 21:31:38 von hexenmeister »

-------------------------

Aktoren, die in einer FHEM-Instanz definiert sind, aus einer anderen schalten
Switch

Definition eines Schalters (EnOcean FSR14)
Code: [Auswählen]

defmod <actor-device-name> EnOcean 0000000B
attr <actor-device-name> IODev FGW14
attr <actor-device-name> alias Licht
attr <actor-device-name> devStateIcon off:light_light_dim_00@gray on:light_light_dim_100@yellow .*:hourglass
attr <actor-device-name> eep A5-38-08
attr <actor-device-name> group Beleuchtung
attr <actor-device-name> gwCmd switching
attr <actor-device-name> icon light_downlight
attr <actor-device-name> manufID 00D
attr <actor-device-name> mqttPublish state:topic=haus/wohnzimmer/licht/top/state
attr <actor-device-name> mqttSubscribe state:stopic=haus/wohnzimmer/licht/top/set
attr <actor-device-name> room Wohnzimmer
attr <actor-device-name> subDef 0010000B
attr <actor-device-name> subType gateway
attr <actor-device-name> webCmd on:off

------------------------

Aktoren, die in einer FHEM-Instanz definiert sind, aus einer anderen schalten
Dimmer

Aktor-Definition:
Code: [Auswählen]

defmod <actor-device-name> CUL_HM xxxxxx
attr <actor-device-name> model HM-LC-Dim1TPBU-FM
...
attr <actor-device-name> mqttPublish pct:topic=haus/wohnzimmer/licht/level state:topic=haus/wohnzimmer/licht/state
attr <actor-device-name> mqttSubscribe pct:stopic=haus/wohnzimmer/licht/set

------------------------

Aktoren, die in einer FHEM-Instanz definiert sind, aus einer anderen schalten
Shutters / Blinds

Aktor-Definition:
Code: [Auswählen]

defmod <actor-device-name> CUL_HM xxxxxx
attr <actor-device-name> model HM-LC-Bl1PBU-FM
...
attr <actor-device-name> mqttPublish pct:topic=haus/wohnzimmer/rollo/all/position state:topic=haus/wohnzimmer/rollo/all/state
attr <actor-device-name> mqttSubscribe pct:stopic=haus/wohnzimmer/rollo/all/set

==FAQ==

Das ist so nicht vorgesehen, ein reading = ein Topic.

a) beim device-count werden nur Geräte gezählt, die mit eigenen mqtt*-Attributen versehen sind. Bei einer globalen Definition 'globalPublish' kann die Bridge nicht (ohne weiteres) wissen, welche Geräte angesprochen werden sollen. Daher wird auch nichts gezählt.

b) mqttSubscribe ist gedacht für diejenigen Geräte, die per MQTT 'versorgt' werden sollen. Die Bridge selbst gehört nicht dazu. Aus technischen Gründen kann es sein, dass diese Attribute trotzdem vom FHEM angeboten werden, gesetzt werden können sie jedoch nicht, die Bridge 'währt' sich dagegen.
Ein 'globalSubscribe' gibt es nicht. Ich habe mich entschieden, diese Festure nicht anzubieten. Bei unbedachten Verwendung könnte ein großes Sicherheitsrisiko entstehen. Einfach diese Attribute an den gewünschgten Devices erstellen.

Die Definition lautet 'fhem room=MQTT_BRIDGE_DEVICES'. Der erste Parameter (wie im Commandref steht) ist der Prefix für die Optionsattribute. Ist für Sonderfälle gedacht, wenn mehr als eine Bridge im System vorhanen ist. Deine Parameter heißen also 'fhemSubscribe' etc.

Bin nun draufgekommen das dieses fehlerhafte Verhalten (Bridge geht nicht nach restart so lange bis man im User Interface DEF und "modify" geklickt hat) nur dann auftritt wenn device-count = 0 ist. Nun hab ich ein Device mit einem "fhemSubscribe" Attribut ausgestattet ... und nun lebt die Bridge auch nach einem Restart.

Du kannst aber mit * alle Readings greifen und dann mit Perlmitteln in der expression filtern.

irgendwie so (ungetestet):
Code: [Auswählen]

desired-temp!info:expression={if($reading=~/SMAEM12345678.*/){$value}else{undef})}

== Hinweise ==
<references />

[[Kategorie:HOWTOS]]
[[Kategorie:MQTT]]

S7 Beispielkonfiguration

2022-01-04T20:59:18Z

Krueuw: /* Vorbereitung */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

====Vorbereitung ====

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls Volker Kettenbach hat dafür im [https://forum.fhem.de/index.php?topic=114284.0 Forum eine Lösung vorgeschlagen], die ich hier realisiert habe. Meine docker-compose.yml sieht dann so aus:

<code>version: '3'</code>

<code>services:</code>

<code> fhem:</code>

<code> image: fhem/fhem:latest</code>

<code> #restart: always</code>

<code> restart: unless-stopped</code>

<code> ports:</code>

<code> - "8083:8083"</code>

<code> - "7072:7072"</code>

<code> volumes:</code>

<code> - ./fhem/core/:/opt/fhem/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.1</code>

<code> devices:</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> environment:</code>

<code> FHEM_UID: 1000</code>

<code> FHEM_GID: 1000</code>

<code> TIMEOUT: 10</code>

<code> RESTART: 1</code>

<code> TELNETPORT: 7072</code>

<code> TZ: Europe/Berlin</code>

<code> depends_on:</code>

<code> - "mysql"</code>

<code> - "mqtt"</code>

<code> habridge:</code>

<code> restart: always</code>

<code> image: habridge/ha-bridge-raspberrypi3</code>

<code> volumes:</code>

<code> - ./habridge/data/:/ha-bridge/data</code>

<code> - /etc/localtime:/etc/localtime:ro</code>

<code> - /etc/timezone:/etc/timezone:ro</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.2</code>

<code># homebridge:</code>

<code># restart: always</code>

<code># image: oznu/homebridge:raspberry-pi</code>

<code># volumes:</code>

<code># - ./homebridge:/homebridge</code>

<code># environment:</code>

<code># - TZ=Europe/Berlin</code>

<code># - PGID=1000</code>

<code># - PUID=1000</code>

<code># - HOMEBRIDGE_CONFIG_UI=1</code>

<code># - HOMEBRIDGE_CONFIG_UI_PORT=8081</code>

<code># #network_mode: host</code>

<code># networks:</code>

<code># default:</code>

<code># ipv4_address: 192.168.31.3</code>

<code># depends_on:</code>

<code># - "fhem"</code>

<code> mysql:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "3306"</code>

<code> - "33060"</code>

<code> ports:</code>

<code> - "3306:3306"</code>

<code> - "33060:33060"</code>

<code> image: hypriot/rpi-mysql</code>

<code> volumes:</code>

<code> - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql</code>

<code> - ./mysql/data:/var/lib/mysql</code>

<code> environment:</code>

<code> - MYSQL_ROOT_PASSWORD=xxx</code>

<code> - MYSQL_DATABASE=fhem</code>

<code> - MYSQL_USER=fhemuser</code>

<code> - MYSQL_PASSWORD=xxx</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.4</code>

<code> mqtt:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1883"</code>

<code> - "9001"</code>

<code> ports:</code>

<code> - "1883:1883"</code>

<code> - "9001:9001"</code>

<code> image: pascaldevink/rpi-mosquitto</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.5</code>

<code> volumes:</code>

<code> - ./mqtt/config/:/mqtt/config/</code>

<code> - ./mqtt/log/:/mqtt/log/</code>

<code> - ./mqtt/data/:/mqtt/data/</code>

<code> nodered:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1880"</code>

<code> ports:</code>

<code> - "1880:1880"</code>

<code> image: elzekool/rpi-nodered</code>

<code> volumes:</code>

<code> - ./nodered/data/:/root/.node-red/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.6</code>

<code> depends_on:</code>

<code> - "mqtt"</code>

<code>networks:</code>

<code> default:</code>

<code> external:</code>

<code> name: mymacvlannetwork</code>

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:

<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-04T16:46:38Z

Krueuw: /* Multicast-Empfang mit Docker */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|mini|Auf dem Bus onewire1 gefundene Sensoren|alternativtext=|ohne]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls Volker Kettenbach hat dafür im [https://forum.fhem.de/index.php?topic=114284.0 Forum eine Lösung vorgeschlagen], die ich hier realisiert habe. Meine docker-compose.yml sieht dann so aus:

<code>version: '3'</code>

<code>services:</code>

<code> fhem:</code>

<code> image: fhem/fhem:latest</code>

<code> #restart: always</code>

<code> restart: unless-stopped</code>

<code> ports:</code>

<code> - "8083:8083"</code>

<code> - "7072:7072"</code>

<code> volumes:</code>

<code> - ./fhem/core/:/opt/fhem/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.1</code>

<code> devices:</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> environment:</code>

<code> FHEM_UID: 1000</code>

<code> FHEM_GID: 1000</code>

<code> TIMEOUT: 10</code>

<code> RESTART: 1</code>

<code> TELNETPORT: 7072</code>

<code> TZ: Europe/Berlin</code>

<code> depends_on:</code>

<code> - "mysql"</code>

<code> - "mqtt"</code>

<code> habridge:</code>

<code> restart: always</code>

<code> image: habridge/ha-bridge-raspberrypi3</code>

<code> volumes:</code>

<code> - ./habridge/data/:/ha-bridge/data</code>

<code> - /etc/localtime:/etc/localtime:ro</code>

<code> - /etc/timezone:/etc/timezone:ro</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.2</code>

<code># homebridge:</code>

<code># restart: always</code>

<code># image: oznu/homebridge:raspberry-pi</code>

<code># volumes:</code>

<code># - ./homebridge:/homebridge</code>

<code># environment:</code>

<code># - TZ=Europe/Berlin</code>

<code># - PGID=1000</code>

<code># - PUID=1000</code>

<code># - HOMEBRIDGE_CONFIG_UI=1</code>

<code># - HOMEBRIDGE_CONFIG_UI_PORT=8081</code>

<code># #network_mode: host</code>

<code># networks:</code>

<code># default:</code>

<code># ipv4_address: 192.168.31.3</code>

<code># depends_on:</code>

<code># - "fhem"</code>

<code> mysql:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "3306"</code>

<code> - "33060"</code>

<code> ports:</code>

<code> - "3306:3306"</code>

<code> - "33060:33060"</code>

<code> image: hypriot/rpi-mysql</code>

<code> volumes:</code>

<code> - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql</code>

<code> - ./mysql/data:/var/lib/mysql</code>

<code> environment:</code>

<code> - MYSQL_ROOT_PASSWORD=xxx</code>

<code> - MYSQL_DATABASE=fhem</code>

<code> - MYSQL_USER=fhemuser</code>

<code> - MYSQL_PASSWORD=xxx</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.4</code>

<code> mqtt:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1883"</code>

<code> - "9001"</code>

<code> ports:</code>

<code> - "1883:1883"</code>

<code> - "9001:9001"</code>

<code> image: pascaldevink/rpi-mosquitto</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.5</code>

<code> volumes:</code>

<code> - ./mqtt/config/:/mqtt/config/</code>

<code> - ./mqtt/log/:/mqtt/log/</code>

<code> - ./mqtt/data/:/mqtt/data/</code>

<code> nodered:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1880"</code>

<code> ports:</code>

<code> - "1880:1880"</code>

<code> image: elzekool/rpi-nodered</code>

<code> volumes:</code>

<code> - ./nodered/data/:/root/.node-red/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.6</code>

<code> depends_on:</code>

<code> - "mqtt"</code>

<code>networks:</code>

<code> default:</code>

<code> external:</code>

<code> name: mymacvlannetwork</code>

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:

<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-04T16:37:58Z

Krueuw: Multicast im Container ergänzt

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Multicast-Empfang mit Docker ====
Die Integration der SMA-PV-Anlage wird bei mir durch das Modul SMAEM erledigt, welches den gesendeten Multicast von HM20 bzw. EM10 für FHEM bereitstellen kann. Diese funktionieren mit Multicast, den das Standard-Bridge-Docker-Netzwerk nicht weiterleiten mag. Der Maintainer des Moduls Volker Kettenbach hat dafür im [https://forum.fhem.de/index.php?topic=114284.0 Forum eine Lösung vorgeschlagen], die ich hier realisiert habe. Meine docker-compose.yml sieht dann so aus:

<code>version: '3'</code>

<code>services:</code>

<code> fhem:</code>

<code> image: fhem/fhem:latest</code>

<code> #restart: always</code>

<code> restart: unless-stopped</code>

<code> ports:</code>

<code> - "8083:8083"</code>

<code> - "7072:7072"</code>

<code> volumes:</code>

<code> - ./fhem/core/:/opt/fhem/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.1</code>

<code> devices:</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> environment:</code>

<code> FHEM_UID: 1000</code>

<code> FHEM_GID: 1000</code>

<code> TIMEOUT: 10</code>

<code> RESTART: 1</code>

<code> TELNETPORT: 7072</code>

<code> TZ: Europe/Berlin</code>

<code> depends_on:</code>

<code> - "mysql"</code>

<code> - "mqtt"</code>

<code> habridge:</code>

<code> restart: always</code>

<code> image: habridge/ha-bridge-raspberrypi3</code>

<code> volumes:</code>

<code> - ./habridge/data/:/ha-bridge/data</code>

<code> - /etc/localtime:/etc/localtime:ro</code>

<code> - /etc/timezone:/etc/timezone:ro</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.2</code>

<code># homebridge:</code>

<code># restart: always</code>

<code># image: oznu/homebridge:raspberry-pi</code>

<code># volumes:</code>

<code># - ./homebridge:/homebridge</code>

<code># environment:</code>

<code># - TZ=Europe/Berlin</code>

<code># - PGID=1000</code>

<code># - PUID=1000</code>

<code># - HOMEBRIDGE_CONFIG_UI=1</code>

<code># - HOMEBRIDGE_CONFIG_UI_PORT=8081</code>

<code># #network_mode: host</code>

<code># networks:</code>

<code># default:</code>

<code># ipv4_address: 192.168.31.3</code>

<code># depends_on:</code>

<code># - "fhem"</code>

<code> mysql:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "3306"</code>

<code> - "33060"</code>

<code> ports:</code>

<code> - "3306:3306"</code>

<code> - "33060:33060"</code>

<code> image: hypriot/rpi-mysql</code>

<code> volumes:</code>

<code> - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql</code>

<code> - ./mysql/data:/var/lib/mysql</code>

<code> environment:</code>

<code> - MYSQL_ROOT_PASSWORD=xxx</code>

<code> - MYSQL_DATABASE=fhem</code>

<code> - MYSQL_USER=fhemuser</code>

<code> - MYSQL_PASSWORD=xxx</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.4</code>

<code> mqtt:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1883"</code>

<code> - "9001"</code>

<code> ports:</code>

<code> - "1883:1883"</code>

<code> - "9001:9001"</code>

<code> image: pascaldevink/rpi-mosquitto</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.5</code>

<code> volumes:</code>

<code> - ./mqtt/config/:/mqtt/config/</code>

<code> - ./mqtt/log/:/mqtt/log/</code>

<code> - ./mqtt/data/:/mqtt/data/</code>

<code> nodered:</code>

<code> restart: always</code>

<code> expose:</code>

<code> - "1880"</code>

<code> ports:</code>

<code> - "1880:1880"</code>

<code> image: elzekool/rpi-nodered</code>

<code> volumes:</code>

<code> - ./nodered/data/:/root/.node-red/</code>

<code> networks:</code>

<code> default:</code>

<code> ipv4_address: 192.168.31.6</code>

<code> depends_on:</code>

<code> - "mqtt"</code>

<code>networks:</code>

<code> default:</code>

<code> external:</code>

<code> name: mymacvlannetwork</code>

Das notwedinge Netz für die Hosts 1 bis 14 dafür habe ich so erzeugt:

<code>docker network create -d macvlan -o parent=eth0 --subnet=192.168.31.0/24 --gateway=192.168.31.254 --ip-range=192.168.31.0/28 mymacvlannetwork</code>

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-03T20:21:06Z

Krueuw:

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2016]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2017]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2018]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-03T20:18:24Z

Krueuw: /* Anpassung von /home/pi/fhem-docker/docker-compose.yml */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2012]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2016]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2017]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5 S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe, belohnt aber mit schneller Darstellung von Diagrammen.

Jetzt ist eine gute Zeit, die SD-Karte als Sicherheitskopie zu klonen.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-03T15:09:01Z

Krueuw: /* Vorbereitung */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2012]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2016]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2017]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /srv</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-03T15:06:55Z

Krueuw: /* Alte Konfiguration in den neuen Container übernehmen */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2012]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2016]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2017]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die neue Grundkonfiguration in der Container-fhem.cfg des Containers unverändert übernommen, alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg hinein kopiert. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

Die [https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen Umstellung] auf das nun eingerichtete DBlog erfordert ein wenig Überlegung und manuelle Eingriffe.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-03T14:58:16Z

Krueuw: /* Serielle Schnittstellen anpassen */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2012]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2016]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2017]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

Da die Version von FHEM schon älter ist, Eingabe von <code>update</code> in die FHEM-Kommandozeile im Browser.

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
dtoverlay=pi3-disable-bt
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die Grundkonfiguration in der neuen fhem.cfg des Containers unverändert übernommen und dann alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg kopiert und in die neue unterhalb eingefügt. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-03T09:27:51Z

Krueuw: /* Vorbereitung */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2012]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2016]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2017]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Keine Fehler auf der Konsole und im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
auskommentieren mit an erster Position eingefügtem # und speichern:
console=serial0,115200
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die Grundkonfiguration in der neuen fhem.cfg des Containers unverändert übernommen und dann alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg kopiert und in die neue unterhalb eingefügt. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-03T08:57:30Z

Krueuw: /* Vorbereitung */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2012]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2016]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2017]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Sollte der Fehler:

<code>ERROR evaluating { DockerImageInfo_HealthCheck(); }: Undefined subroutine &main::DockerImageInfo_HealthCheck called at (eval 47) line 1.</code>

auftreten, hilft es in /home/pi/fhem-docker/fhem/core/fhem.cfg, nach einem vorherigen Backup dieser Datei, folgende Zeilen aufzunehmen:

<code>define myDIInfo DockerImageInfo</code>

<code>attr myDIInfo DbLogExclude .*</code>

<code>attr myDIInfo alias Docker Image Info</code>

<code>attr myDIInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red</code>

<code>attr myDIInfo group Update</code>

<code>attr myDIInfo icon docker</code>

<code>attr myDIInfo room System</code>

Erfolgskontrolle: Im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

==== Serielle Schnittstellen anpassen ====
Die Module S7 und OWX brauchen im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
auskommentieren mit an erster Position eingefügtem # und speichern:
console=serial0,115200
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die Grundkonfiguration in der neuen fhem.cfg des Containers unverändert übernommen und dann alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg kopiert und in die neue unterhalb eingefügt. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-01T17:57:44Z

Krueuw: /* Docker mit Integration von Nodered, MQTT, IOBroker [2022] */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2012]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2016]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2017]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich habe mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Erfolgskontrolle: Im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

==== Serielle Schnittstellen anpassen ====
Für die S5 und OWX brauche ich im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
auskommentieren mit an erster Position eingefügtem # und speichern:
console=serial0,115200
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die Grundkonfiguration in der neuen fhem.cfg des Containers unverändert übernommen und dann alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg kopiert und in die neue unterhalb eingefügt. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-01T17:56:35Z

Krueuw:

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann. Ausgangspunkt ist eine seit 1997 gewachsene S5-95U-Haussteuerung. Inzwischen wurde diese um eine FHEM-Anbindung in einer Docker-Umgebung ergänzt. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt ab 2012 chronologisch dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen [2012]==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen [2016]==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN [2017]===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker [2022] ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich haber mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Erfolgskontrolle: Im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

==== Serielle Schnittstellen anpassen ====
Für die S5 und OWX brauche ich im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
auskommentieren mit an erster Position eingefügtem # und speichern:
console=serial0,115200
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die Grundkonfiguration in der neuen fhem.cfg des Containers unverändert übernommen und dann alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg kopiert und in die neue unterhalb eingefügt. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-01T17:43:16Z

Krueuw: /* Anpassung von /home/pi/fhem-docker/docker-compose.yml */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann.
Ausgangspunkt ist eine in 20 Jahren gewachsene S5-95U-Haussteuerung. Inzwischen wurde begonnen diese um eine FHEM-Anbindung zu ergänzen. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt hier dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich haber mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Erfolgskontrolle: Im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

==== Serielle Schnittstellen anpassen ====
Für die S5 und OWX brauche ich im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
auskommentieren mit an erster Position eingefügtem # und speichern:
console=serial0,115200
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die Grundkonfiguration in der neuen fhem.cfg des Containers unverändert übernommen und dann alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg kopiert und in die neue unterhalb eingefügt. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht.

==== Fazit ====
Die Simatic S5 hat es ins Docker-Zeitalter geschafft ;-) kann Daten per MQTT publishen und subscriben, Daten mit Node-Red visualisieren und potenziell nun auch IOBroker-kompatibel werden.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-01T17:35:01Z

Krueuw: /* Serielle Schnittstellen anpassen */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann.
Ausgangspunkt ist eine in 20 Jahren gewachsene S5-95U-Haussteuerung. Inzwischen wurde begonnen diese um eine FHEM-Anbindung zu ergänzen. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt hier dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich haber mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Erfolgskontrolle: Im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

==== Serielle Schnittstellen anpassen ====
Für die S5 und OWX brauche ich im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 für die S5 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
auskommentieren mit an erster Position eingefügtem # und speichern:
console=serial0,115200
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für /dev/ttyAMA0 und die drei über USB angeschlossenen Onewire-Bus-Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Aktivierung der Rules mit:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

Gruppenzugehörigkeit ändern:

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Eigentümer setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann die mitgelieferte docker-compose.yml (tippfehlerfrei) angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern der docker-compose.yml, die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle auf der Pi-Konsole mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die Grundkonfiguration in der neuen fhem.cfg des Containers unverändert übernommen und dann alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg kopiert und in die neue unterhalb eingefügt. Nach einem <code>shutdown restart</code> funktionierte dann (fast) alles wie gewünscht und die S5 hat es ins Docker-Zeitalter geschafft ;-)
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-01T17:24:10Z

Krueuw: /* Vorbereitung */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann.
Ausgangspunkt ist eine in 20 Jahren gewachsene S5-95U-Haussteuerung. Inzwischen wurde begonnen diese um eine FHEM-Anbindung zu ergänzen. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt hier dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich haber mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich auf einem Ubuntu-PC so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Erfolgskontrolle: Im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

==== Serielle Schnittstellen anpassen ====
Für die S5 und OWX brauche ich im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
auskommentieren mit an erster Position eingefügtem # und speichern:
console=serial0,115200
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für alle benötigen seriellen Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Danach:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Rechte setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann docker-compose.yml angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch _Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die Grundkonfiguration in der fhem.cfg des Containers unverändert übernommen und dann alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg kopiert und in die neue unterhalb eingefügt. Nach einem shutdown restart funktionierte dann (fast) alles wie gewünscht.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-01T17:22:39Z

Krueuw: /* Anpassung von /home/pi/fhem-docker/docker-compose.yml */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann.
Ausgangspunkt ist eine in 20 Jahren gewachsene S5-95U-Haussteuerung. Inzwischen wurde begonnen diese um eine FHEM-Anbindung zu ergänzen. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt hier dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich haber mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich unter Ubuntu so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Erfolgskontrolle: Im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

==== Serielle Schnittstellen anpassen ====
Für die S5 und OWX brauche ich im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
auskommentieren mit an erster Position eingefügtem # und speichern:
console=serial0,115200
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für alle benötigen seriellen Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Danach:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Rechte setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann docker-compose.yml angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch _Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per <code>get onewire1 devices</code> eine Liste der angeschlossenen OW-Geräte sichtbar sein:
[[Datei:OWX-Geräte-Liste.png|rand|links|mini|Auf dem Bus onewire1 gefundene Sensoren]]

Damit ist alles bereit und die Test-Geräte S7 und OWX müssen im Webinterface gelöscht und die eventuell automatisch erkannten Sensoren manuell aus der fhem.cfg entfernt werden. Danach FHEM <code>shutdown restart</code>.

==== Alte Konfiguration in den neuen Container übernehmen ====
Ich habe die Grundkonfiguration in der fhem.cfg des Containers unverändert übernommen und dann alle Zeilen unterhalb der Basiskonfigruation der alten fhem.cfg kopiert und in die neue unterhalb eingefügt. Nach einem shutdown restart funktionierte dann (fast) alles wie gewünscht.
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

Datei:OWX-Geräte-Liste.png

2022-01-01T17:09:32Z

Krueuw:

OWX-Geräte-Liste

S7 Beispielkonfiguration

2022-01-01T17:07:04Z

Krueuw: /* Serielle Schnittstellen anpassen */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann.
Ausgangspunkt ist eine in 20 Jahren gewachsene S5-95U-Haussteuerung. Inzwischen wurde begonnen diese um eine FHEM-Anbindung zu ergänzen. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt hier dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich haber mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich unter Ubuntu so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Erfolgskontrolle: Im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

==== Serielle Schnittstellen anpassen ====
Für die S5 und OWX brauche ich im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu Anleitung] wird die /dev/ttyAMA0 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
auskommentieren mit an erster Position eingefügtem # und speichern:
console=serial0,115200
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Jetzt weiter für alle benötigen seriellen Schnittstellen:

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Danach:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Pi-User zuordnen:

<code>sudo adduser $USER tty</code>

<code>sudo adduser $USER dialout</code>

Rechte setzen:

<code>sudo chmod g+r /dev/ttyUSB0</code>

<code>sudo chmod g+r /dev/ttyUSB1</code>

<code>sudo chmod g+r /dev/ttyUSB2</code>

<code>sudo chmod g+r /dev/ttyAMA0</code>

<code>sudo reboot</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun unter anderem eine Schnittstelle ttyAMA0 zeigen.

==== Anpassung von /home/pi/fhem-docker/docker-compose.yml ====
Für OWX ist die feste Zuordnung mehrerer Onewire-Adapter wichtig. [https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ Dieser Befehl] zeigt eindeutige Namen, die auch nach dem Umstecken der USB-Stecker gültig bleiben:

<code>ls -l /dev/serial/by-id</code>

Das Ergebnis sieht bei mir so aus:

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0 -> ../../ttyUSB0</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0 -> ../../ttyUSB2</code>

<code>lrwxrwxrwx 1 root root 13 1. Jan 16:23 usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0 -> ../../ttyUSB3</code>

Entsprechend kann dann docker-compose.yml angepasst werden:

 <code>networks:</code>

<code> - fhem-network</code>

<code> devices:</code>

<code> # - "/dev/ttyUSB0:/dev/ttyUSB0"</code>

<code> - "/dev/ttyAMA0:/dev/ttyAMA0"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01XC9Y-if00-port0:/dev/onewire3"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E5-if00-port0:/dev/onewire2"</code>

<code> - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E6-if00-port0:/dev/onewire1"</code>

Nach dem Speichern die Container mit <code>docker-compose down</code> bzw. <code>docker-compose up -d</code> neustarten.

Erfolgskontrolle mit <code>docker exec -it fhem-docker_fhem_1 /bin/bash</code>:

<nowiki>#</nowiki> ls -l /dev

..

<code>crw-rw---- 1 root tty 188, 0 Jan 1 17:53 onewire1</code>

<code>crw-rw---- 1 root tty 188, 1 Jan 1 15:12 onewire2</code>

<code>crw-rw---- 1 root tty 188, 2 Jan 1 16:26 onewire3</code>

..

<code>exit</code>

Test der Schnittstellen in FHEM durch _Einfügen der Befehle in die Browser-Kommandozeile:

<code>define myS5t S7 S5 /dev/ttyAMA0</code> sollte im Webinterface zum state '''connected''' führen.

<code>define onewire3 OWX /dev/onewire3</code> sollte im Webinterface zum state '''opened''' führen.

Nach einiger Zeit sollte per
[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-01T16:28:55Z

Krueuw: /* Serielle Schnittstellen anpassen */

Dieser Artikel beschreibt eine Beispielkonfiguration für die SPS-Hardware [[S7|Siemens S5]]. Eine Anpassung an die S7 bzw. Logo ist mit meist sehr geringem Aufwand möglich, weil das selbe Modul verwendet werden kann.
Ausgangspunkt ist eine in 20 Jahren gewachsene S5-95U-Haussteuerung. Inzwischen wurde begonnen diese um eine FHEM-Anbindung zu ergänzen. Ich demonstriere die vorhandenen Möglichkeiten, indem ich meinen Arbeitsfortschritt hier dokumentiere.

__TOC__

==Status von S5-Ausgängen in FHEM anzeigen==
Nachdem der FHEM-Host z.B. ein Raspberry Pi über die normale Programmierleitung wie [[Siemens_S5_Vorbemerkungen_f%C3%BCr_Einsteiger#Hardware|hier]] beschrieben verbunden ist, können auf der FHEM-Kommandozeile im WEB-Interface folgende Befehle eingegeben werden.

Bei mir wird die biologische Nachklärung des Abwassers mit einem [http://images.google.de/imgres?imgurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/images/launh.gif&imgrefurl=http://www.hgreibaum-kleinklaeranlagen-erdbau.de/launh.html&h=347&w=600&tbnid=wfyoztNN7sVVuM:&vet=1&tbnh=90&tbnw=156&docid=xl2wKluoAEYsmM&hl=en&client=browser-ubuntu&usg=__zwf8AXZ04gHEqR2A7MmRon_OKEw=&sa=X&ved=0ahUKEwjd1KiYtIzRAhXceVAKHTf6B5sQ9QEIPDAD Launhardt-Reaktor] erledigt. Drei Pumpen werden durch die S5-Ausgänge A13.0 .. A13.2 zeitgesteuert geschaltet. In FHEM soll der Status der Ausgänge angezeigt werden. Dazu müssen nur die betreffenden Ausgänge in FHEM bekannt gemacht werden. Änderungen am S5-Programm sind nicht notwendig.

define s5test S7 S5 /dev/ttyAMA0

define Abpumpen S7_DRead outputs 0 13.0
attr Abpumpen IODev s5test
attr Abpumpen icon icoBaum
attr Abpumpen room Abwasser
attr Abpumpen sortby 03

define Umpumpen S7_DRead outputs 0 13.1
attr Umpumpen IODev s5test
attr Umpumpen icon audio_repeat
attr Umpumpen room Abwasser
attr Umpumpen sortby 02

define Zupumpen S7_DRead outputs 0 13.2
attr Zupumpen IODev s5test
attr Zupumpen icon scene_toilet_alternat
attr Zupumpen room Abwasser
attr Zupumpen sortby 01

[[File:Launhardt-web.png|mini|ohne|Erfolgskontrolle]]

==vorhandene S5-Lampensteuerung um FHEM ergänzen==
Das S5-Programm für das Schalten der Beleuchtung mittels Taster soll auch bei ausgefallenem FHEM funktionieren wie bisher. Dazu schaltet FHEM spezielle Merker, die dann per ODER mit den anderen Eingängen verknüpft werden, hier Merker M 65.0 (vier ergänzte Zeilen):

NETZWERK 12 Arbeitszimmer
00AC :U(
00AD :U(
00AE :O E 64.7 Taster im Arbeitszimmer
00AF :O M 65.0 Merker für FHEM
00B0 :)
00B1 :UN M 61.4 Flankenmerker
00B2 :S A 65.7 Lampe Arbeiten Giebel
00B3 :U(
00B4 :O E 64.7 Taster im Arbeitszimmer
00B5 :O M 65.0 Merker für FHEM
00B6 :)
00B7 :U M 61.4 Flankenmerker
00B8 :R A 65.7 Lampe Arbeiten Giebel
00B9 :U A 65.7 Lampe Arbeiten Giebel
00BA :)
00BB :UN E 64.7 Taster im Arbeitszimmer
00BC :UN M 65.0 Merker für FHEM
00BD :S M 61.4 Flankenmerker
00BE :UN E 64.7 Taster im Arbeitszimmer
00BF :UN M 65.0 Merker für FHEM
00C0 :UN A 65.7 Lampe Arbeiten Giebel
00C1 :R M 61.4 Flankenmerker
00C2 :NOP 0
:***
'''zugehörige FHEM-Konfiguration:'''
define s5test S7 S5 /dev/ttyAMA0 #FHEM Hardwarezugriff konfigurieren

define M65.0 S7_DWrite flags 0 65.0 #S5-Merker M65.0 für FHEM-Schreibzugriff
attr M65.0 IODev s5test #M65.0 an /dev/ttyAMA0 ist gemeint
attr M65.0 eventMap /on-for-timer 1 /trigger:tasten #1-s-Impuls außerdem Web: trigger -> tasten
attr M65.0 icon light_pendant_light #Standard-Icon ersetzen
attr M65.0 room Arbeitszimmer #Raumzuordnung zur optischen Gruppierung
attr M65.0 webCmd tasten #Button auf Weboberfläche gelabelt als "tasten"

Das Merkerbyte 65 muss für den FHEM-Schreibzugriff reserviert sein. Die Lampe kann nun zusätzlich über das Webinterface oder die Smartphone-App geschaltet werden.

==Namenskonvention für S5-FHEM-Projekt==
Um ein gewachsenes Projekt mit erträglichem Aufwand in die neue Zeit zu retten, dabei die Übersicht nicht zu verlieren, hat sich in Anlehnung an [https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html FISCHER-NET.DE] ein strukturiertes Namensschema bewährt. Die langen FHEM-Namen passen nur als Symbolik-Kommentar in die S5. Ergänzung 2022: Die Punkte als Trennzeichen habe ich inzwischen durch Unterstriche ersetzt, um die leichter Regex in FHEM verwenden zu können.

'''Der Aufbau der Namen:''' A.B.C.D ab 2022 als A_B_C_D
A Ort im Gebäude oder auf dem Grundstück
B Raum oder nähere Örtlichkeit
C Gerät
D Zweck

Heizungsvorlauf Temperatursensor im Obergeschoss: OG.hr.DS1820.Hz_VL

Rollladen im Schlafzimmer öffnen: OG.sz.M1763.RlHo

'''A ID Beschreibung'''
KG Kellergeschoß
EG Erdgeschoß
OG Obergeschoß
SB Spitzboden
AB Außenbereich

'''B ID Beschreibung'''
wa Wanne
du Dusche
wz Wohnen, Weg
fl Flur
cp Carport
hr Heizung
hv Holzvergaser
k Keller
ku Küche
sz Straße
sz Schlafen

'''C <Gerätename>'''

'''D <Zweck>'''

==FHEM-S5-Lampensteuerung tastbar um ein/aus ergänzen==

Bei einem Wandtaster kann entschieden werden, welchen Zustand die Lampe hat, weil man sie sieht. Anders beim Webinterface, hier wäre ein gezieltes ein- bzw. ausschalten besser, weil man eventuell entfernt handelt. Damit läßt sich auch eine zentrales Licht-AUS bzw. eine Alarmbeleuchtung mit ALLES-AN realisieren. Je ein 16-Bit-Word wird für das Tasten, das Einschalten bzw. das Ausschalten vorgesehen. Das reicht für maximal 16 Lampen. Hier also das MW164 für Tasten, MW166 für Ein und MW168 für AUS. M164.7 für das Tasten, M166.7 für EIN und M168.7 für AUS der Giebellampe. Die notwendigen Konfigurationen für weitere Lampen können so innerhalb der fhem.cfg kopiert und brauchen nur minimal angepasst werden. Ich empfehle vor Manipulationen der fhem.cfg unter Umgehung des dafür vorgesehenen Webinterfaces unbedingt ein Backup dieser Datei anzufertigen.

'''S5-Programm nochmals ergänzt'''

NETZWERK 12 Arbeitszimmer
00AC :O(
00AD :U(
00AE :U(
00AF :O -AzLiGt E64.7 Lichttaster
00B0 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00B1 :)
00B2 :UN -AzLaGf M61.4 Flankenmerker
00B3 :)
00B4 :O -M 166.7 M166.7 OG.Az.M1667.LaGiEin FHEM
00B5 :S -AzLaG A65.7 Lampe Arbeiten Giebel
00B6 :O(
00B7 :U(
00B8 :O -AzLiGt E64.7 Lichttaster
00B9 :O -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00BA :)
00BB :U -AzLaGf M61.4 Flankenmerker
00BC :)
00BD :O -M 168.7 M168.7 OG.Az.M1667.LaGiAus FHEM
00BE :R -AzLaG A65.7 Lampe Arbeiten Giebel
00BF :U -AzLaG A65.7 Lampe Arbeiten Giebel
00C0 :)
00C1 :UN -AzLiGt E64.7 Lichttaster
00C2 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C3 :S -AzLaGf M61.4 Flankenmerker
00C4 :UN -AzLiGt E64.7 Lichttaster
00C5 :UN -M 164.7 M164.7 OG.Az.M1647.LaGiTast FHEM
00C6 :UN -AzLaG A65.7 Lampe Arbeiten Giebel
00C7 :R -AzLaGf M61.4 Flankenmerker
00C8 :NOP 0
[[File:FUP-Giebellampe.png|mini|ohne|Funktionsplan der Licht-Steuerung]]

'''zugehöriger Abschnitt aus der fhem.cfg'''
define s5test S7 S5 /dev/ttyAMA0

define OG.az.M1647.LichtGtast S7_DWrite flags 0 164.7
attr OG.az.M1647.LichtGtast IODev s5test
attr OG.az.M1647.LichtGtast alias Giebellampe
attr OG.az.M1647.LichtGtast eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1647.LichtGtast icon light_pendant_light
attr OG.az.M1647.LichtGtast room Arbeitszimmer
attr OG.az.M1647.LichtGtast webCmd tasten

define OG.az.M1667.LichtGaus S7_DWrite flags 0 166.7
attr OG.az.M1667.LichtGaus IODev s5test
attr OG.az.M1667.LichtGaus alias Giebellampe.aus
attr OG.az.M1667.LichtGaus eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1667.LichtGaus icon light_light
attr OG.az.M1667.LichtGaus room Arbeitszimmer
attr OG.az.M1667.LichtGaus webCmd tasten

define OG.az.M1687.LichtGein S7_DWrite flags 0 168.7
attr OG.az.M1687.LichtGein IODev s5test
attr OG.az.M1687.LichtGein alias Giebellampe.an
attr OG.az.M1687.LichtGein eventMap /on-for-timer 1 /trigger:tasten
attr OG.az.M1687.LichtGein icon light_light_dim_100
attr OG.az.M1687.LichtGein room Arbeitszimmer
attr OG.az.M1687.LichtGein webCmd tasten

Das FHEM-Gerät trägt nun einen strukturierten Namen, um es leicht zuordnen zu können. Auf der grafischen Oberfläche ist dies durch die Raumzuordung überflüssig. Hier wird der Alias Giebellampe verwendet. Außerdem kann man es gezielt aus- bzw. eintasten.

[[File:Giebellampe2.png|mini|ohne|Erfolgskontrolle]]

==FHEM-S5-Rolladensteuerung ergänzen==

In meiner S5 existiert bisher ein Programm welches nur einen Taster mit hoch - stop - runter - stop verwendet. Bei der Rolladensteuerung über das Webinterface ist es sinnvoller je einen Button für das Hochfahren, einen für das Runterfahren und einen für STOP zu konfigurieren. Wie bei der Lampenschaltung soll sich auch hier ein zentrales HOCH bzw. RUNTER für alle vorhandenen Rolläden realisieren lassen. Dazu werden in der S5 das Merkerbyte MB176 bzw. M176.3 für HOCH und MB178 bzw. M178.3 für RUNTER und MB177 bzw. M177.3 für STOP für den FHEM-Zugriff konfiguriert. Damit sind maximal acht Rollläden .0 bis .7 möglich.

'''S5-Programm'''

NETZWERK 2 RL Schlafen hoch
0012 :O(
0013 :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
0014 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0015 :)
0016 :UN -RDNS A10.5 Ausgang RLaden runter Schlafen
0017 :L KT 030.2
0019 :SA T 5 Timer Schlafen hoch
001A :O -RDNS A10.5 Ausgang RLaden runter Schlafen
001B :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
001C :O -RStopS M19.4 RL Stop
001D :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
001E :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
001F :R T 5 Timer Schlafen hoch
0020 :NOP 0
0021 :NOP 0
0022 :U T 5 Timer Schlafen hoch
0023 := -RUPS A10.4 Ausgang RLaden hoch Schlafem
0024 :***

NETZWERK 3 RL Schlafen runter
0025 :O(
0026 :O -XRDNS M19.3 Tasterauswertung RL Schlafen run
0027 :O -M 178.3 M178.3 OG.Sz.M1763.RlRu FHEM
0028 :)
0029 :UN -RUPS A10.4 Ausgang RLaden hoch Schlafen
002A :L KT 030.2
002C :SA T 6 Timer Schlafen runter
002D :O -RUPS A10.4 Ausgang RLaden hoch Schlafen
002E :O -XRUPS M19.2 Tasterauswertung RL Schlafen hoc
002F :O -RStopS M19.4 RL Stop
0030 :O -M 177.3 M177.3 OG.Sz.M1763.RlStop FHEM
0031 :O -M 176.3 M176.3 OG.Sz.M1763.RlHo FHEM
0032 :R T 6 Timer Schlafen runter
0033 :NOP 0
0034 :NOP 0
0035 :U T 6 Timer Schlafen runter
0036 := -RDNS A10.5 Ausgang RLaden runter Schlafen
0037 :***

[[File:FUP-RL.png|mini|ohne|Funktionsplan der Rollladensteuerung]]

Der Motorschutz-Timer sorgt dafür, dass die Stromversorgung nach der maximalen Laufzeit abgeschaltet wird.

'''zugehöriger Abschnitt aus der fhem.cfg'''

Die Zeilen mit event-min-interval und .*:600 event-on-change-reading state dienen wie im [[S7#Ger.C3.A4teunabh.C3.A4ngige_Konfigurationsdetails|S7-Wiki]] beschrieben der Geschwindigkeitsverbesserung.

define OG.sz.M1763.RlHo S7_DWrite flags 0 176.3
attr OG.sz.M1763.RlHo IODev s5test
attr OG.sz.M1763.RlHo alias Rollladen.hoch
attr OG.sz.M1763.RlHo event-min-interval .*:600
attr OG.sz.M1763.RlHo event-on-change-reading state
attr OG.sz.M1763.RlHo eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1763.RlHo icon rc_UP
attr OG.sz.M1763.RlHo room Schlafen
attr OG.sz.M1763.RlHo sortby 01
attr OG.sz.M1763.RlHo webCmd tasten

define OG.sz.M1773.RlStop S7_DWrite flags 0 177.3
attr OG.sz.M1773.RlStop IODev s5test
attr OG.sz.M1773.RlStop alias Rollladen.stop
attr OG.sz.M1773.RlStop event-min-interval .*:600
attr OG.sz.M1773.RlStop event-on-change-reading state
attr OG.sz.M1773.RlStop eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1773.RlStop icon rc_REC
attr OG.sz.M1773.RlStop room Schlafen
attr OG.sz.M1773.RlStop sortby 02
attr OG.sz.M1773.RlStop webCmd tasten

define OG.sz.M1783.RlRu S7_DWrite flags 0 178.3
attr OG.sz.M1783.RlRu IODev s5test
attr OG.sz.M1783.RlRu alias Rollladen.runter
attr OG.sz.M1783.RlRu event-min-interval .*:600
attr OG.sz.M1783.RlRu event-on-change-reading state
attr OG.sz.M1783.RlRu eventMap /on-for-timer 1 /trigger:tasten
attr OG.sz.M1783.RlRu icon rc_DOWN
attr OG.sz.M1783.RlRu room Schlafen
attr OG.sz.M1783.RlRu sortby 03
attr OG.sz.M1783.RlRu webCmd tasten

'''Ergebnis'''

[[File:rl-web.png|mini|ohne|Erfolgskontrolle]]

Der Rolladen kann nun über das Webinterface auf beliebigen Geräten gezielt geschlossen bzw. geöffnet werden.

==FHEM-S5-Bewässerungssteuerung ergänzen==

Bisher können vier Gartenschläuche mit Perlschläuchen über Magnetventile per Taster bzw. Zeitschaltung betrieben werden. Zusätzlich soll warmes Wasser zugemischt werden können, um eine Überhitzung der Dachkollektoren zu verhindern. Die Zeitschaltung ist nur äußerst unkomfortabel über einen Datenbaustein zu konfigurieren und wurde daher kaum benutzt. Im Ergebnis lief das Wasser im Garten oft unkontrolliert über viele Stunden. Ziel mit FHEM ist eine deutliche Verbesserung. Zunächst wird die Einschaltzeit per FHEM auf 90 min begrenzt.
[[File:Qe-bewaesserung.png|mini|ohne|Schaltplan der Bewässerung]]
wird fortgesetzt wenn es wieder wärmer ist ..

==FHEM-S5-Heizungssteuerung neu anlegen==
Nachdem die S5-Unterstützung fester Bestandteil von FHEM ist und vorher auch keine Probleme mit dem verwendeten S7-Modul auftraten, geht es jetzt ans Eingemachte - die Steuerung der Heizung. Die Steuerung soll nun (fast) ausschließlich von FHEM erledigt werden, weil es damit leichter möglich ist umfangreiche Abhängigkeiten abzubilden und entsprechenden Module fertig zur Verfügung stehen. Die S5 dient hier nur noch als "dumme" Ausgangsklemme für die von FHEM gesteuerten Aktoren. Damit soll der Aufwand und die Komplexität der Steuerung reduziert werden. Eine Anpassung des S5-Programms soll so kaum noch notwendig sein, um auch das lästige Umstecken der PG-Schnittstelle zu erledigen.
===Sensorik mit OWX===
Im ersten Schritt habe ich die bisherige analoge Temperaturmessung mit [http://www.sprut.de/electronic/temeratur/temp.htm gemultiplexten B511] am Analogeingang der SPS durch [[:Kategorie:1-Wire|Sensoren am 1-Wire-Bus]] ersetzt, um mehr Messtellen ohne aufwändige Kalibrierung und Verkabelung zu bedienen und auch die Luftfeuchte und die solare Einstrahlung zu messen. FHEM stellt die zwei weitgehend getrennten Module owserver und OWX zur Unterstützung des 1-Wire-Busses zur Verfügung. Nach erfolgreichen Tests ist es OWX geworden, weil hier ohne Umwege über zum Teil [https://forum.fhem.de/index.php?topic=56881.0 haklige Fremdsoftware-Installationen] direkt mit Perl auf den Bus zugegriffen wird. Bisher läuft das Verfahren stabil.

Zunächst benötigt man eine von OWX unterstützte Hardware, um auf den 1-Wire-Bus zuzugreifen. Ich habe mich für die zuverlässigere Variante Raspi -> USB -> 1-wire über einen [http://www.fuchs-shop.com/de/shop/17/1/13372195/ DS9097U kompatiblen Adapter] und gegen die [https://forum.fhem.de/index.php?topic=11709.0 wackligeren Varianten] entschieden. Nützlich dazu war die Anleitung von [https://waschto.eu/owx waschto.eu].{{Randnotiz | RNTyp=y | RNText=Um die Ausfallsicherheit der Temperaturmessung zu erhöhen, sollte das verwendete USB-Devices so wie [https://wiki.siduction.de/index.php?title=Symlink_zur_eindeutigen_Erkennung_mittels_udev-Regel hier] beschrieben fest dem Adapter zugeordnet werden. Sonst kann es passieren, dass beim Umstecken von USB-Geräten unbemerkt der gesamte Bus ausfällt. }}

Empfehlenswerte kombinierte Sensoren für Temperatur und Luftfeuchtigkeit bzw. Einstrahlung habe ich [http://www.tm3d.de/shop/ hier] gekauft. Für die restlichen Temperaturmesstellen sind es fertig konfektionierte DS1820 mit Hülse geworden, wie man sie sehr preiswert bei z.B. ebay bekommt.

Viel Zeit kann man vertrödeln, wenn man die korrekte Busverkabelung als Nebensache ansieht. Korrekt sieht sie entsprechend der Diskussion im Forum so aus: [[Datei:korrekte_1-wire_Verkabelung.jpg|mini|ohne|1-Wire-Busverdrahtung nach PAH]]
Diese [[1-Wire_Busverlegung#Verbindung_verschiedener_Kabeltypen|LSA+ Boxen]] habe ich für den direkten Anschluss bzw. für über max. 3 m lange Stubs von konfektionierten Sensoren verwendet und sonst Abzweige in Feuchtraumabzweigdosen mit Data-Return-Ader über Leuchtenklemmen hergestellt. Noch besser ist womöglich die im [https://forum.fhem.de/index.php?topic=21473.0 Forum] empfohlenen [http://www.reichelt.de/WAGO-250-210/3/index.html?ACTION=3&GROUPID=7539&ARTICLE=100838&SHOW=1&OFFSET=16& Variante]. Mögliche Problemlösungen sind [https://forum.fhem.de/index.php/topic,56881.30.html hier] dokumentiert. Als Leitungsmaterial für die gewählte Verbindungstechnik hat sich bei mir für ca. 100 m, Telefonleitung für feste Verlegung YStY 2x2x0,6 bewährt.

Bei der Sensor-Installation bin ich mit Hilfe der OWX-Automatik schrittweise vorgegangen, um die Übersicht zu behalten:
*Status von OneWire unter Unsorted im WEB-Interface muss Active sein,
*ersten Sensor einzeln an den Bus geklemmt,
*in der Detailansicht {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste mit dem ersten Sensor in die Textdatei owx1 kopiert,
*owx1 als owx-uebersicht gespeichert und den Zweck des Sensors ergänzt,
*config nicht gespeichert!, um Sensoren immer wieder komplett neu abzufragen,
*shutdown restart ausgeführt, damit OWX den ersten Sensor vergisst,
*nächsten Sensor zusätzlich an den Bus geklemmt,
*In der Detailansicht wieder {{Taste|get}} Onewire {{Taste|devices}} ausgewählt,
*die erscheinende Liste in die Textdatei owx2 kopiert,
*Dateien owx1 und owx2 mit Meld (diff-Programm) verglichen, um den zweiten Sensor zu separieren,
*Differenz in owx-uebersicht einfügt und Zweck ergänzt,
*Differenz nach owx1 übernommen, für den neuen IST-Zustand,
*usw. usf.
*erst wenn der letzte Sensor erkannt wurde, fhem.cfg gespeichert,
*Sensoren entsprechend dem Benennungsschema und Zweck umbenannt:

rename OWX_20_FF0939521603 OG.hr.DS1820.Hz

fhem.cfg Ausschnitt komplett mit Zuordnung und Lastoptimierung für den FHEM-Host:

define OG.hr.DS1820.Hz_VL OWTHERM DS18B20 FF0939521603
attr OG.hr.DS1820.Hz_VL IODev OneWire
attr OG.hr.DS1820.Hz_VL alias Hz-VL
attr OG.hr.DS1820.Hz_VL event-min-interval 60
attr OG.hr.DS1820.Hz_VL event-on-change-reading temperature:0.3
attr OG.hr.DS1820.Hz_VL group FBH-Mischer,Fußboden
attr OG.hr.DS1820.Hz_VL model DS18B20
attr OG.hr.DS1820.Hz_VL room Heizung
attr OG.hr.DS1820.Hz_VL sortby 01

[[Datei:Owx-ergebnis.png|mini|ohne|Erfolgskontrolle]]

===Heizkreis-Regelung mit PWM===

Die Ansteuerung der 230-V-Heizkreis-Thermoantriebe habe ich ohne Änderung aus der alten SPS-Steuerung übernommen. Sie werden direkt mit einer kontaktlosen S5-230-V-Ausgabebaugruppe geschaltet. [[Datei:Fhem-s5-ta.png|mini|ohne|Ansteuerung der Thermoantriebe der Heizkreisventile]]
[[Datei:6es5451-8md11.jpg|mini|ohne|230 V Ausgabemodul]]

Das Modul [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|FHEM-PWM]] ist für die Einzelraumregelung von geschalteten Fußbodenheizungen vorgesehen. Es liest einen Temperatursollwert aus den Voreinstellungen, bildet daraus und aus der gemessenen IST-Raumtemperatur eine Regelabweichung und schaltet entsprechend die Heizkreise so, dass der SOLL-Wert schnell und ohne nennenswertes Überschwingen erreicht wird. Die Definition von PWM und PWMR am Beispiel eines Raumes in FHEM:

define fh PWM

define OG.wo.PWMR PWMR fh 0.7,0 OG.wo.DS1820.TF OG.hr.M706.TAwo
attr OG.wo.PWMR alias Wohnen-Soll
attr OG.wo.PWMR autoCalcTemp 1
attr OG.wo.PWMR group Raum
attr OG.wo.PWMR room Heizung,Wohnen
attr OG.wo.PWMR tempDay 19
attr OG.wo.PWMR tempNight 16
attr OG.wo.PWMR tempRule1 Mo-Fr 11:00,D 20:00,N
attr OG.wo.PWMR tempRule2 Sa-So 6:00,D 20:00,N

Also, das Gerät fh definiert und je Raum ein Define von PWMR mit dem Raumfühler und dem Schalter für das Ventil als Parameter - fertig und funktioniert. Leider haben sich mir weitere Funktionen des Moduls bisher nicht erschlossen. Bitte am [[Steuerung_einer_Fussbodenheizung_mit_dem_PWM-Modul|Wiki]] mitarbeiten.

Um die Funktion von PWM zu visualisieren, kann man eine [[Plots_erzeugen|grafische Darstellung]] in Form eines Diagramms definieren:

define OG.wo.graph.dummy dummy
attr OG.wo.graph.dummy event-on-change-reading state

define OG.wo.temp at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS1820.TF", "temperature",0);;$d= 'OG.wo.temp '.$d;; fhem("set OG.wo.graph.dummy $d")}

define FLog_OG.wo.graph.dummy FileLog ./log/OG.wo.graph.dummy-%Y-%m-%d.log OG.wo.graph.dummy
attr FLog_OG.wo.graph.dummy logtype text

define OG.wo.humidity at +*00:05:00 { my $d= ReadingsVal("OG.wo.DS2438.RF","relHumidity",0);;$d= 'OG.wo.humidity '.$d;; fhem("set OG.wo.graph.dummy $d")}

define OG.wo.TA at +*00:05:00 { my $d= ReadingsVal("OG.hr.A190.TAwo","state",0);;$d= 'OG.wo.TA '.$d;; fhem("set OG.wo.graph.dummy $d")}

define SVG_FLog_OG.wo.graph.dummy_1 SVG FLog_OG.wo.graph.dummy:SVG_FLog_OG.wo.graph.dummy_1:CURRENT

[[Datei:Wz chart.png|mini|ohne|Erfolgskontrolle]]

===Regelung der FBH-Vorlauftemperatur mit dem Modul PID20===

Die Temperatur des Heizungswassers welches die Fußbodenheizungskreise durchströmt, sollte für Brennwertgeräte so niedrig wie möglich sein, um deren Wirkungsgrad zu verbessern. Hier geht es in erster Linie darum, dass das Wasser aus den Pufferspeichern des Holzvergasers mindestens auf die maximal zulässige Temperatur heruntergekühlt wird, um eine hohe Lebensdauer der Heizung zu gewährleisten. Als Mischventil verwende ich ein günstiges gebrauchtes fast lautlos arbeitendes Gerät [https://www.downloads.siemens.com/download-center/Download.aspx?pos=download&fct=getasset&id1=10416 Siemens MXG461], welches von der S5 mit 0..10 V analog angesteuert werden kann:

[[Datei:MXG461.png|mini|ohne|MXG461]]

Bei der S5-95U kann man dazu den internen Analogausgang verwenden:

[[Datei:MXG461 ansteuern.png|mini|ohne|Verbindung 95U - MXG461]]

Die Programmierung innerhalb der S5 kann so wie [http://gaxons.com/files/s5/s5_handbuch.pdf im Handbuchsiehe 3.3.5 und 12.2.2] beschrieben realisiert werden. Mit Hilfe des intern bereits vorhandenen Bausteins FB251 gelingt das leicht. Aufruf und Parametrierung des FB251 für das Mischventil mit: obere Grenze = 100, voll offen und: untere Grenze = 0 geschlossen.

: SPA FB 251
NAME : RLG:AA
XE : MW130
BG : KF=8
KNKT : KY=0,0
OGR : KF=100
UGR : KF=0
FEH : M 131.0
BU : M 131.1

Die Stellgröße im Bereich von 0..100 muss nun von FHEM-PID20 in das Merkerwort MW130 der S5 geschrieben, eventuelle Fehlermeldungen von der S5 als FEH und BU zurückgeliefert werden.

'''16 Bit Merkerwort zum Schreiben'''
define OG.hr.MW130.Mischventil S7_AWrite flags 0 130 u16
attr OG.hr.MW130.Mischventil IODev s5test
attr OG.hr.MW130.Mischventil alias Ventilstellung
attr OG.hr.MW130.Mischventil event-min-interval .*:600
attr OG.hr.MW130.Mischventil event-on-change-reading state
attr OG.hr.MW130.Mischventil group FBH-Mischer
attr OG.hr.MW130.Mischventil room Heizung
attr OG.hr.MW130.Mischventil sortby 01

'''Definition des PID-Reglers'''
define PID.Test PID20 OG.hr.DS1820.Hz_VL:temperature OG.hr.MW130.Mischventil:
attr PID.Test group FBH-Mischer
attr PID.Test pidActorErrorPos 0
attr PID.Test pidActorInterval 1
attr PID.Test pidCalcInterval 20
attr PID.Test pidReverseAction 1
attr PID.Test room Heizung

'''SPS-Konfigurationsfehler melden'''
define OG.hr.M1301.FEH S7_DRead flags 0 131.0
attr OG.hr.M1301.FEH IODev s5test
attr OG.hr.M1301.FEH alias SPS-Konfiguration
attr OG.hr.M1301.FEH devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.FEH event-min-interval .*:600
attr OG.hr.M1301.FEH event-on-change-reading state
attr OG.hr.M1301.FEH group FBH-Mischer
attr OG.hr.M1301.FEH room Heizung
attr OG.hr.M1301.FEH sortby 03

'''FHEM-Stellgrößen-Bereichsüberschreitung melden'''
define OG.hr.M1301.BU S7_DRead flags 0 131.1
attr OG.hr.M1301.BU IODev s5test
attr OG.hr.M1301.BU alias FHEM-Sollwert
attr OG.hr.M1301.BU devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr OG.hr.M1301.BU event-min-interval .*:600
attr OG.hr.M1301.BU event-on-change-reading state
attr OG.hr.M1301.BU group FBH-Mischer
attr OG.hr.M1301.BU room Heizung

[[Datei:Fhem-s5-mv.png|mini|ohne|Erfolgskontrolle]]

===Warmwasserspeicherladung mit DOIF===
Wenn die Temperatur im Pufferspeicher des Holzvergasers OG.ks.DS1820.P500o deutlich höher ist als im Warmwasserspeicher OG.hr.DS1820.wwo, soll dieser geladen werden, indem das Ventil mit Hilfe eines 230 V Thermoantriebes OG.hr.M710.TAWW für den integrierten Wärmetauscher geöffnet wird. Ich benutze dazu die FHEM-Funktion [[DOIF]].

define OG.hr.WW.oben_heizen DOIF
(([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 8)) or\
(([OG.hr.DS1820.wwo:temperature:d] < 41) and
([OG.ks.DS1820.P500o:temperature:d] > ([OG.hr.DS1820.wwo:temperature:d] + 4))))\
(set OG.hr.M710.TAWW on;; set OG.hr.M700.HzPu on)
DOELSE (set OG.hr.M710.TAWW off;; set OG.hr.M700.HzPu off)
attr OG.hr.WW.oben_heizen alias TA_WW
attr OG.hr.WW.oben_heizen devStateIcon cmd_1:10px-kreis-rot cmd_2:10px-kreis-gruen
attr OG.hr.WW.oben_heizen do resetwait
attr OG.hr.WW.oben_heizen group Warmwasser
attr OG.hr.WW.oben_heizen room Heizung
attr OG.hr.WW.oben_heizen sortby 04
attr OG.hr.WW.oben_heizen wait 120

===Visualisierung des Heizungsschemas mit FLOORPLAN===
Um einen schnellen Überblick über den Gesamtzustand der Heizungsanlage zu ermöglichen, ist die grafische Variante [[Floorplan]] besser als die FHEM-Ansicht mit Variable = Wert geeignet. Die Alternative [[YAF]] macht ebenfalls einen guten Eindruck. Sie speichert die Konfiguration aber nicht vollständig in der fhem.cfg und notwendige Anpassungen werden nur halbherzig betrieben. Die Anpassung an zukünftige Entwicklungen war für mich daher zu fraglich.

Zunächst habe ich das Heizungsschema mit [[https://qelectrotech.org/ Qelectrotech 0.5]] gezeichnet. Das Programm ist dazu gut geeignet, auch wenn der Name anderes suggeriert. Die fertige Zeichnung wird als PNG-Datei (oder SVG) gespeichert und als Hintergrundbild entsprechend der ausführlichen Beschreibung im [[Floorplan|Wiki]] eingefügt. Die Beeinflussung der Darstellungsdetails direkt über die zuständige CSS-Datei eröffnet alle Möglichkeiten ist aber sehr gewöhnungsbedürftig.

[[File:Heizungsschema2.png|mini|ohne|Heizungsschema]]

Danach können interessante Schaltzustände und Messwerte integriert und auch später noch im WEB-Interface bearbeitet werden. Details werden in der fhem.cfg gespeichert, eine Bearbeitung an dieser Stelle erscheint mir eher weniger geeignet. Für jedes interessierende Anlagendetail kann eine neue Seite des Floorplans verwendet werden.

[[Datei:Fp heizungsschema.png|mini|ohne|Erfolgskontrolle]]

==Docker mit Integration von Nodered, MQTT, IOBroker ==
Nodered ist m.E. eine ideale Ergänzung zu FHEM und ein attraktives visuelles Frontend. Für die Integration habe ich mich an den Videos von Matthias Kleine und [https://haus-automatisierung.com/ seiner Seite Hausautomatisierung] orientiert.

Für FHEM und angrenzende Dienste gibt es für den Raspi ein [https://github.com/fhem/fhem-docker offizielles Docker-Image], welches offenbar auch auf Vorarbeiten von Matthias zurück geht. Ich zeige, wie meine bestehende Installation in den Container umzog.

==Vorbereitung ==

Ich haber mich entschlossen, auch aus Sicherheitsgründen, auf einer neuen SD-Karte, hier in einem neuen Raspi4, ein komplett neues System aufzusetzen. Ein Raspi3 würde aber genügen.
[[Datei:Raspberry Pi OS Imager.png|alternativtext=Raspberry PI OS Lite (32-bit) auf der SDC installieren|links|mini|Raspberry PI OS Lite (32-bit) auf der SDC installieren]]

Der Imager lässt sich unter Ubuntu so installieren:

<code>sudo apt update</code>

<code>sudo apt install snapd</code>

<code>sudo snap install rpi-imager</code>

Nach dem Start des neuen Systems, mit <code>sudo raspi-config</code> folgende Einstellungen ändern:
# System Options -> Password
# Interface Options -> SSH
# Localisation Options -> L1 bis L4
Docker kann nach dem SSH-Login <code>ssh pi@<raspi-IP></code> nach [https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html Anleitung] auf dem Raspi installiert werden:

<code>sudo apt-get update</code>

<code>sudo apt-get upgrade</code>

<code>sudo reboot</code>

<code>sudo apt-get install wget git apt-transport-https vim telnet</code>

<code>curl -sSL <nowiki>https://get.docker.com</nowiki> | sh</code>

<code>sudo systemctl enable docker</code>

<code>sudo systemctl start docker</code>

<code>sudo usermod -aG docker pi</code>

<code>cd /home/pi</code>

<code>git clone -b raspbian <nowiki>https://github.com/klein0r/fhem-docker.git</nowiki> fhem-docker</code>

<code>cd fhem-docker</code>

<code>sudo apt-get install python-pip</code>

<code>sudo pip install docker-compose</code>

<code>exit</code>

Dann erneut per ssh anmelden.
<code>cd fhem-docker</code>

<code>docker-compose up</code>
Erfolgskontrolle: Im Browser unter <raspi-ip>:8083/fhem sollte nach ein paar Minuten ein optisch und technisch entstaubtes FHEM (und auf anderen Ports die anderen Dienste) zu sehen sein. Falls keine Fehlermeldungen in der SSH-Session zu sehen sind, docker-compose mit <Strg>+<c> abbrechen und die Container im Hintergurnd neu starten mit:

<code>docker-compose up -d</code>

==== Serielle Schnittstellen anpassen ====
Für die S5 und OWX brauche ich im Container die seriellen Schnittstellen. Diese sind standardmäßig nicht dabei. Nach [https://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3-4/ Anleitung] wird die /dev/ttyAMA0 zunächst auf dem Raspi aktiviert:
$ sudo nano /boot/config.txt
am Ende hinzufügen:
enable_uart=1
auskommentieren mit an erster Position eingefügtem # und speichern:
console=serial0,115200
<code>sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service</code>

Datei mit unten stehendem Inhalt anlegen: /etc/udev/rules.d/99-ttyAMA0.rules:

<code>KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660”</code>

<code>KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660”</code>

Danach:

<code>sudo udevadm control --reload-rules && sudo udevadm trigger</code>

<code>sudo chgrp -h tty /dev/serial0</code>

<code>sudo chgrp -h tty /dev/serial1</code>

<code>sudo chgrp -h tty /dev/serial2</code>

<code>sudo chgrp -h tty /dev/serial3</code>

Erfolgskontrolle auf dem Raspi: <code>ls -l /dev</code> sollte nun eine Schnittstelle ttyAMA0 zeigen.

Für OWX kann die feste Zuordnung mehrerer Onewire-Adapter über

== disable the serial console: sudo systemctl stop serial-getty@ttyS0.service && sudo systemctl disable serial-getty@ttyS0.service ==

== make sure you have pyserial installed if you're using the python serial library, not python-serial from apt. ==

== create the following file /etc/udev/rules.d/ttyAMA0.rules: ==

== KERNEL==“ttyUSB0”, SYMLINK+=“serial0” GROUP=“tty” MODE=“0660” ==

== KERNEL==“ttyUSB1”, SYMLINK+=“serial1” GROUP=“tty” MODE=“0660” ==

== KERNEL==“ttyUSB2”, SYMLINK+=“serial2” GROUP=“tty” MODE=“0660” ==

== KERNEL==“ttyAMA0”, SYMLINK+=“serial3” GROUP=“tty” MODE=“0660” ==

== and reload your udev rules: sudo udevadm control --reload-rules && sudo udevadm trigger ==

== change the group of the new serial devices ==

== sudo chgrp -h tty /dev/serial0 ==

== sudo chgrp -h tty /dev/serial1 ==

== sudo chgrp -h tty /dev/serial2 ==

== sudo chgrp -h tty /dev/serial3 ==

== The devices are now under the tty group. Need to add the user to the tty group and dialout group: ==

== sudo adduser $USER tty ==

== sudo adduser $USER dialout ==

== update the permissions for group read on the devices ==

== sudo chmod g+r /dev/ttyUSB0 ==

== sudo chmod g+r /dev/ttyUSB1 ==

== sudo chmod g+r /dev/ttyUSB2 ==

== sudo chmod g+r /dev/ttyAMA0 ==

== reboot ==

== Quelle: <nowiki>https://raspberrypi.stackexchange.com/questions/114366/rpi4-serial-port-not-working-on-either-raspberry-os-or-ubuntu</nowiki> ==

[[Kategorie:Siemens PLC]]
[[Kategorie:Examples]]

S7 Beispielkonfiguration

2022-01-01T16:18:59Z

Krueuw: /* Serielle Schnittstellen anpassen */

S7 Beispielkonfiguration

2022-01-01T16:03:27Z

Krueuw: /* Umzug */

S7 Beispielkonfiguration

2022-01-01T15:45:51Z

Krueuw: /* Umzug */

S7 Beispielkonfiguration

2022-01-01T15:27:02Z

Krueuw: /* Docker */

Datei:Raspberry Pi OS Imager.png

2022-01-01T14:44:42Z

Krueuw:

OS für Docker auswählen