FHEMWiki - Benutzerbeiträge [de]

First steps in FHEM

2024-12-31T20:03:59Z

Afo-solar: In the English wiki the page "Import-of-Code-Snippets" is missing, hence I deleted the phrase "please note this article Import-of-Code-Snippets". I corrected the German word "und" in the headline "Event-driven timer start - notify und at" to the English word "and".

This a beginners course for those starting to work with FHEM. After you have installed FHEM on your server you may reproduce all steps without any additional smart home hardware.

This guide was originally published by Ulrich Maass, who gave his permission to publish it in the FHEM wiki.

Note to editors: Everybody is welcome to improve typo, grammar and style. Content changes and extentions should be discussed with the author (e. g. on associated [[Diskussion:First_steps_in_FHEM|discussion page]]).

== First attempt ==
To start FHEM for the first time, enter in your browser's address field:
<nowiki>http://<ip-address>:8083</nowiki>
e. g. <nowiki>http://192.168.1.1:8083</nowiki>.

The FHEM homepage is displayed:

[[Datei:ErsteSchritteInFhem01.png|border]]

* At the top of the screen you can see the white ''command line'' where you can enter commands.
* The first menu item is the ''Save config'' button, which saves changes so that they are still available even after a restart.
* Furthermore, there are already the rooms ''Unsorted'' and ''Everything'' that we will soon get to know
* In the lower block there are further links, which we will also discuss later.

The ''Security Check'' note indicates that you have not yet set a password for FHEM. To set up password protection, see the FHEM command reference {{Link2CmdRef|Anker=allowed}}, which contains a description of all FHEM functions and modules. To suppress this message for now, enter the following in the command line:
attr global motd none
and confirm this change with {{Taste|Enter}} or click on the link of the same name.

[[Datei:ErsteSchritteInFhem02.png|border]]

== Creating device - define ==
The basic element of FHEM is called ''device''.Typical devices are, for example, remote controlled outlets, roller shutter motors, temperature sensors, solenoid valves etc.

But other things that at first glance wouldn't appear to be a physical device are devices: for example, the user interface of FHEM itself is a device (''"FHEMWEB"''), and there are devices without physical equipment that can be used to store a variable.

We will now create a very simple device, called ''dummy''.

A dummy device is a special object in that it does not necessarily require a corresponding physical device (physical lamp, roller shutter, solenoid valve). In this way, you can carry out these steps without any hardware, and you can go through this general introduction without having to deal with the differences between the various hardware systems. A dummy device typically looks exactly the same in the FHEM interface as a FHEM device corresponding to a physical device in your hardware environment.

First, we'll create a switch. This simulates a light switch in the wall. To do this, enter the following command in the command field:
define mySwitch1 dummy

"define" is the needed FHEM command, "mySwitch1" the future name of our device, "dummy" describes its type. The words "define" and "dummy" are part of FHEM's command syntax and cannot be modified, "mySwitch1" is (more or less) arbitrary. After pressing {{Taste|Enter}} the detailed view of our new FHEM device ''mySwitch1'' is displayed.

[[Datei:ErsteSchritteInFhem03.png|border]]

{{Hinweis|Each device has exactly one "type". This type also defines the Perl command file (more precisely referred to as the "module") in which certain routines and properties are coded. Since our device is of type ''dummy'', FHEM knows that the routines and properties are located in module 98_dummy. pm. (The number 98 used to have a meaning, but today this is no longer the case, though it is still used for historical reasons.)}}

Devices have a "state" that changes over time and that FHEM records. For example, a window is opened, a roller shutter curtain is closed and a radio socket is alive. A state does not have to contain exactly one variable (window either "open" or "closed"), a state can also be described by several variables (the state of a raspberry system, device-type sysmon, includes for example the CPU frequency, the CPU temperature, the workload and much more).

The device status in FHEM consists of three blocks of values, called ''Internals'', ''Attributes'' and ''Readings''. It would be too early to go into the meaning of the three terms in detail, but the following remarks are important for the following steps:
* ''Internals'' store very basic information about a device. They are rarely edited directly by the user (usually only during device setup).
* ''Attributes'' control device behavior. Typically they can be changed (or even defined) by users.
* ''Readings'' have, in contrast to the values of the other two blocks, a timestamp. Usually they are measured values of your device.

It may be confusing for beginners that there could be Internals and Readings with the same names (e.g. STATE and state). However, Perl is case sensitive!

{{Hinweis|Block '''''Internals''''' always shows basic characteristics of a FHEM device:
*'''''NAME:''''' device name assigned by the user
*'''''TYPE:''''' device type of FHEM device, here: ''dummy''
*'''''STATE:''''' device state shown in all summaries. Since there was no assignment till now it is initially '''''???'''''.}}

== Creating rooms ==

Let's do a step forward and arrange our devices in rooms. You may consider it reasonable to put together devices physically (really) located in one room into a FHEM room. So you can find in "''bedroom''" appropriate devices like "''shutter''", "''time switch''" and "''radio set''". You may decide other assignments: put all measuring devices like thermometers, electric meters and hygrometers in one (possibly only virtually and not physically existing) room "''measuring devices''". Name of a room is arbitrary.

To achieve this you have to add to all devices which your room should contain an "Attribute" (see above). Name of the attribute is "room" and it should get as its value the room name. Let's try it with our room ''dummy''. Use command
attr mySwitch1 room Training
and finish input with {{Taste|Enter}}).

With this command you have added to device ''mySwitch1'' Attribute ''room'' with value ''Training''. Again, ''attr'', ''mySwitch1'' (while referencing to an existing object's name) and ''room'' are part of FHEM's command syntax and are unalterable, ''Training'' is arbitrary.

Now ''mySwitch1'' belongs to room ''Training''. Due to this assignment room appears in navigation bar on the left hand side in room's block. Try to click at room ''Training''.

[[Datei:ErsteSchritteInFhem04.png]]

FHEM will show all devices belonging to this room. Until now we have only one device: ''mySwitch1'' - our dummy.

Beside device name always device status is on display, we still get ''???''. Clicking at name ''mySwitch1'' you will return to its detailed view.

Our dummy is shown in a block with (type) label ''dummy''. You may change label as well introducing a further attribute "''group''" and assigning to it (arbitrary as well) name: groups order devices inside a room.

'''Note''': If you want to delete a room, you may do so by removing all devices from this room. In our example of room ''Training'' you have to delete attribute room in all devices of room ''Training''. Room ''Training'' will disappear by itself.

== Creating switching commands ==
Now we want to add on/off buttons to "mySwitch1":
attr mySwitch1 webCmd on:off

Again we use an attribute named webCmd with values on:off, we want to add to device "mySwitch1". Instead of entering mentioned above command into command line field you may choose desired attribute (in this case: '''''webCmd''''') in lower part of detail view and enter needed values into text field right next, in this case '''''on:off'''''. Complete your input with a click on button {{Taste|attr}}.

[[Datei:ErsteSchritteInFhem05.png]]

Now let's click again on room ''Training''.

You may see, that due to attribute added in last step in room view switch buttons for ''on'' and ''off'' have appeared.

[[Datei:ErsteSchritteInFhem06.png]]
Experimentally click on ''on'' and ''off'': instead of ''???'' you got so far you may find a bulb symbol showing current state.

Clicking on device name ''mySwitch1'' you change back to detail view and may see in block ''Internals'' current state ''STATE'' - being shown in room view as an icon (bulb).

[[Datei:ErsteSchritteInFhem07.png]]

In detail view you can see a new block ''Readings'' as well.

Please switch off ''mySwitch1'' once again. Pay attention to readings: next to internal ''STATE'' you may find a reading of same name (see above: Perl distinguishes lower and upper case), but equipped with a timestamp. Check reading ''state'' for updating at value and timestamp.

== Event monitor ==

Please, open in your browser another window with FHEM and in FHEM its '''[[Event monitor]]'''. The shortest way is to right-click on ''Event monitor'' and to select from the local menu "Open in new window". Place windows in such a way, that you can follow event monitor and operate your "mySwitch1" at once. Using Windows 7 or newer simply activate one window and press {{Taste|Windows}}+{{Taste|Pfeil rechts}}, followed by activating second window and pressing {{Taste|Windows}}+{{Taste|Pfeil links}}.

[[Datei:ErsteSchritteInFhem08.png]]

Devices communicate via events. One device sends an event to FHEM and FHEM distributes this event to all devices. Devices decide whether to react or not and if yes - how. Let's have a closer look at this.

Switching ''mySwitch1'' FHEM generates an event. With every actuation of the switch yet another event appears in ''Event monitor''. Please look what happens when you consecutively click twice on ''on''.

Events always consist of a timestamp followed by the type of the triggering device (in this case: ''dummy''), name of the triggering device (in this case: ''mySwitch1'') as well as triggered command (in this case: ''on'' or ''off'').

FHEM devices like remotes or remote-controlled wall switches, which trigger physical events, generate events in FHEM with every keypress in device itself or click on associated FHEM device.

Understanding events, their structure and operation is crucial - we will frequently need them below.

== Operating devices - set ==

So you have learned to switch ''mySwitch1'' clicking at ''on'' or ''off''. Alternatively you can use command line entering instructions there.

So please, enter in command line field <code>set mySwitch1 on</code> or <code>set mySwitch1 off</code> and confirm this with button {{Taste|Enter}}. Switching status will change accordingly as well and an Event will be triggered. By the way, we will frequently use command ''set'' in future.

Preparing further tests we now create a new device '''''myLamp1''''' that we later on want to control with '''''mySwitch1'''''.
define myLamp1 dummy

Since ''myLamp1'' is a lamp - an actor - it won't get buttons for ''on'' or ''off''.

Lamp should be located in room ''Training''. You might set this assignment via command line, like shown above. But this time we will use computer mouse...

Until now ''myLamp1'' has no room assignment, so it appears in room ''Unsorted''. Switch over to this room and click at name ''myLamp1'' getting to detail view.

In the lower part we can set attribute assignments.

Attribute ''room'' is already selected (as default). When you click at text field next to ''room'', a dialog box opens that contains all rooms FHEM knows so far. You may select one ore more checkboxes and assign this or these rooms to device. Now select only room ''Training'' and confirm selection with button {{Taste|OK}}. Selected room will be transferred into text field and it remains only to click at button {{Taste|attr}} to activate assignment.

[[Datei:ErsteSchritteInFhem09.png]]

Now change back to room ''Training'' and you will see both devices:

[[Datei:ErsteSchritteInFhem10.png]]

== Event trigger - notify ==
Now we will enable FHEM to react to an event of ''mySwitch1'': Every time ''mySwitch1'' is triggering event with command ''on'' we want to switch on ''myLamp1''.

For it FHEM uses a "notify". Defining syntax looks like
define <NAME> notify <REGEXP> <command>

* Name '''<NAME>''' will help us to find this FHEM device and display its properties. This time we name the device ''n_mySwitch1_on'' - ''n_'' for marking it a notify, followed by the name of triggering device and triggering command. Such a name may seem too complicated but it is very useful when working with a whole bunch of notifies. You may name it if desired ''n1'' or ''John Doe''. Device names may consist of characters '''a-z''', '''A-Z''', '''0-9''', '''_ (underscore)''' and '''. (period)''' with a period not at first position. In perl and therefore in FHEM period has a special meaning, so avoid if possible periods in device names.
*'''<REGEXP>''' stands for "regular expression" and describes a condition for raising notify. We will meet regular expressions in perl and FHEM frequently. They are used to describe syntactical characteristics of strings, e. g. whether a string contains a given word or not, whether digits are in our string and much more. Whenever in FHEM an event raises for every notify runs a check for regexp matching. In our case ''mySwitch1'' raises an event with command ''on''. To "catch" this event and react to it we have notation <code>mySwitch1:on</code>. In future you will have many more moments to deal with regexps in detail. :)
*'''<command>''' tells what to do. In our case: <code>set myLamp1 on</code>.

So our notify looks like
define n_mySwitch1_on notify mySwitch1:on set myLamp1 on

After you have entered this in command field followed by {{Taste|Enter}}, you will see again detail view of the new FHEM notify device (see TYPE).

[[Datei:ErsteSchritteInFhem11.png]]

In block ''Internals'' you can find definition '''DEF'''. Here you see all text you have entered in event definition after the word "notify" (device type). So you can see ''<regexp>'' and ''<command>''.
{{Hinweis|In Block '''''Probably associated with''''' you can find all FHEM devices associated with this notify. Devices are listed as clickable device names, so you can jump over with only one click to detail view of the respective device.}}

Please assign notify to room ''Training'' (find in the lower part attribute ''room'' and choose correct room followed by a click at ''attr'').

So clicking in FHEM's main menu at ''Training'' you will get our three FHEM devices.

[[Datei:ErsteSchritteInFhem12.png]]

{{Hinweis|Usally a notify wouldn't be assigned to a room since it shouldn't be visible to user later on. We will do it anyway for our training purposes.}}

Now switch ''mySwitch1'' to ''on'' - ''myLamp1'' will be switched too. It seems that it works only at first time, but checking event monitor or looking in ''myLamp1'''s detail view at timestamp of last state change you can notice that it executes every time.

To get it working for switching off too we define a second notify:
define n_mySwitch1_off notify mySwitch1:off set myLamp1 off

Does it work as expected?

Doubtless you dislike defining an own notify for every command a device should raise. You can get it easier.

Instead of
define n_mySwitch1_on notify mySwitch1:on set myLamp1 on
define n_mySwitch1_off notify mySwitch1:off set myLamp1 off
we define
define n_mySwitch1 notify mySwitch1 set myLamp1 '''$EVENT'''
We see that this time regexp doesn't differ events ''on'' and ''off'' of ''mySwitch1''. With an absent regexp declaration notify raises for any event with whatsoever command. In executing set command we use FHEM variable '''$EVENT''' (follow the capital notation!). This is a placeholder for the command taken over from the raising event. Having from ''mySwitch1'' an ''on'', '''$EVENT''' will stand for value ''on'' too, accordingly for ''off'' and any other command.

== Deleting or disabling devices – delete, disable ==
Looking at Event Monitor you see that after activation of ''mySwitch1'' command for ''myLamp1'' is executed twice. The reason is, that any event of ''mySwitch1'' is caught by two notifies - by the "old" notify as well as by the new one. To avoid this we should get rid of the old one. For that purpose we have two choices.

#'''Delete''' a notify with command <code>delete <name></code>, e. g. with <code>delete n_mySwitch1_on</code>. By the way, command <code>delete</code> works with any object in FHEM. So you can delete this way "real" devices too.
#'''Deactivate''' a notify, using attribute ''disable''. You can assign it in detail view of the related notify. (Choose the attribute ''disable'' in drop-down menu next to {{Taste|attr}} in lower part and choose value ''1'' with a following click at {{Taste|attr}}.) Or enter in command line: <code>attr n_mySwitch1_off disable 1</code>.

== Save Config ==
Whenever you are satisfied with the current state of your FHEM configuration, click on '''''Save config''''' in the top left corner of the FHEM menu or enter the command <code>save</code> in the command field followed by {{Taste|Enter}}. Your configuration is now saved. If you do not do this, all changes will be lost after the next FHEM restart. FHEM therefore reminds you of unsaved changes with a red question mark next to '''''Save config'''''.

== Modifying existing devices – modify ==

We now create a second lamp, which should also be switched by our ''mySwitch1'' and our Notify. The new lamp is created by entering the following in the command field:
define myLamp2 dummy

With several clicks in the detail screen of ''myLamp2'' you can also assign them to the room Training and assign buttons for ''on'' and ''off'' via the ''webCmd'' attribute.

[[Datei:ErsteSchritteInFhem13.png]]

Now we adjust the Notify ''n_mySwitch1''. To do this, navigate to the Notify detail screen: Switch to the ''Training'' room and click on the name of ''n_mySwitch1''.

In the detail screen there is the line ''DEF'', which we have already looked at before. If you click on the word ''DEF'', you can edit the definition of an FHEM object.

{{Hinweis|The ''DEF'' field displays only the part of the definition that followed the object type, i. e. notify, as you created this notification. Here you will find the regex to which the Notify reacts, then the command to be executed after an empty space. For the sake of readability, the entire define statement is always shown below, even if it is not completely visible in the ''DEF'' field.}}

We change here from
define n_mySwitch1 notify mySwitch1 set myLamp1 $EVENT
to
define n_mySwitch1 notify mySwitch1 set myLamp1,myLamp2 $EVENT

[[Datei:ErsteSchritteInFhem14.png]]

To finish editing click on the ''''modify <name>'''' button, i. e. {{Taste|modify n_mySwitch1}}. If you check the details in the detail screen, you will see that the ''DEF''inition of the notify has been adjusted.

[[Datei:ErsteSchritteInFhem14B.png]]

Note again that in the detail screen below under ''Probably associated with'' the switched lamps will appear in the lower section of the detail screen - this will often be useful.

{{Hinweis|By the way, you can use the link ''''Device specific help'''' to view the complete help text for your device type from commandref, i. e. the help text for ''notify''. This link is often helpful, especially at the beginning.}}

Now you can test whether a click on ''mySwitch1'' really switches both lamps. Take a look at the events in a separate window with the Event Monitor.

[[Datei:ErsteSchritteInFhem15.png]]

== Switching a couple of devices at once ==

For switching several devices can therefore be used
set <device1>,<device2> on

An alternative spelling for it is
set <device1> on; set <device2> on

Also a combination is possible:
set <device1>,<device2> on; set <device3> off

Even within a notify (or other FHEM commands) you can list several commands, but here is one thing to note:
define n1 notify mySwitch1:on set myLamp1 on;set myLamp2 off
The commands are separated by a semicolon. Effect is: The notify switches myLamp1 whenever mySwitch1 sends the event on. The next command in this line is ''set myLamp2 off''. This is processed '''immediately''' when the above-mentioned command line is entered. It switches myLamp2 immediately, myLamp1 only after the mySwitch1 event.

If the second command ''set myLamp2 off'' should also be executed after the event, a double semicolon must be used:
define n1 notify mySwitch1:on set myLamp1 on;;set myLamp2 off

The combined variant could look like this:
define n1 notify mySwitch1:on set myLamp1 on;;set myLamp2 off;set myLampe3 on
This command line would switch myLamp3 immediately, but only after the mySwitch1 event myLamp1 and myLamp2 switch.

== Renaming devices ==

Finally we want to rename (for the exercise) another device: '''''myLamp2''''' should be '''''myStandardLamp'''''. For this we use
rename <oldName> <newName>

It should be noted that related notify statements are '''not''' updated automatically. So, before renaming, note the ''Probably associated with'' list at the bottom of the detail screen so that you do not forget any of your Notify during the following adjustment.

So enter in the command box
rename myLamp2 myStandardLamp
and then adjust ''n_mySwitch1'' by customizing the definition on its detail screen in the 'DEF' section.

After the change, the Notify must be
define n_mySwitch1 notify mySwitch1 set myLamp1,myStandardLamp $EVENT

[[Datei:ErsteSchritteInFhem16.png]]

== Scheduler - at ==
The next step is to set up a time control.
First of all, we want to ensure that ''myLamp1'' is switched off after one minute, such as a staircase light.

{{Hinweis|To see the effect, first switch ''myLamp1'' to ''on''.}}

The FHEM device type ''at'' is available for time control. The command structure is
define <name> at <timespec> <command>
'''<name>''' and '''<command>''' have the same function here as with notify. New here is only '''<timespec>''' (time specification), so the time specification. This is done in the notation ''HH:MM:SS'' or ''HH:MM''.

To turn off '''''myLamp1''''' so '''in one minute''', create the following ''at'':
define a_myLamp1 at +00:01:00 set myLamp1 off

[[Datei:ErsteSchritteInFhem17.png]]

Try it.
Will ''myLamp1'' be turned off after one minute?
Is an event generated during this process?

If you want to see the detail view of the ''at'', you have to hurry up: After a single execution, the ''at'' is automatically deleted. If FHEM was faster, you can create it again and specify a longer period of time if necessary. :-)

With <timespec> you can omit the seconds and just write HH:MM. There are also several variants:
{|class="wikitable"
|+Variants of time specifications for ''at''
|-
!notation
!explanation
|-
|style="text-align: right;"|+00:02:00
|In two minutes; single execution
|-
|style="text-align: right;"|00:02:00
|At two minutes past midnight, i.e. at 00:02 and 0 seconds; one-time execution
|-
|style="text-align: right;"|*00:02:00
|Daily at 00:02
|-
|style="text-align: right;"|+*00:02:00
|Every 2 minutes
|-
|style="text-align: right;"|+*{3}00:02
|Three times, every two minutes
|-
|style="text-align: right;"|*{3}00:02
|Three times at 00:02
|-
|style="text-align: right;"|*{sunset_rel()}
|Daily at sunset
|-
|style="text-align: right;"|*{sunrise(+120)}
|2 minutes (120 seconds) daily after sunrise
|}
*By specifying '''*''' a permanent repetition is defined. The repetitions continue until the ''at'' is deleted or disabled.
*By specifying '''+''' the specified time is no longer interpreted as an absolute time, but as a timer, after how many hours:minutes:seconds the command is executed.
*By specifying '''''{n}''''' the ''at'' will only be run n times.
*The functions '''''{sunset_rel()}''''' and '''''{sunrise()}''''' return the appropriate time. This is repeated daily by specifying '''''*'''''. The curly braces indicate that FHEM directly executes the contents of these braces as perl functions.

For example, to switch off the garden lighting every day at sunrise, define something like
define a_gardenLight_morning_off at *{sunrise()} set gardenLight off

[[Datei:ErsteSchritteInFhem18.png]]

In the detail screen of an ''at'' the time of the next execution is displayed in the ''STATE''.

This info also appears in the room view if you show the ''at'' there:

[[Datei:ErsteSchritteInFhem18B.png]]

== Event-driven timer start - notify and at ==
{{Randnotiz|RNText='''Time and Event Control with DOIF'''
Since the release of the original article in early 2014, another way of time and event control has been introduced. See: {{Link2CmdRef|Anker=DOIF}} for DOIF}}
As a last exercise we want to combine a ''notify'' and an ''at''. The timer should now not start when you enter the command in the command field, but when an event occurs.

[[Datei:GotoRAW-Import firststeps.PNG|thumb|left|300px]]For this purpose, we create a Stairwell: create the Dummy-Devices ''sw_Switch'' and ''sw_Light'' in the ''room Stairwell''. In order to enter the following commands on one piece, click the framed "+" icon next to the command line (only available in the default Style f18), add the following lines with copy&paste to the dialog box that appears and press {{Taste|Execute}}:
define sw_Switch dummy
attr sw_Switch room Stairwell
attr sw_Switch webCmd on
define sw_Light dummy
attr sw_Light room Stairwell
[[Datei:RAW-Import firststeps.PNG]]

Then you can close the dialog or enter the following commands. Note that with ''Execute'' all statements from the dialog box are executed, which may lead to error messages e.g. if a device has already been defined before. Lines with commands that have already been adopted into the configuration can therefore confidently delete to avoid such effects.

Now the Notify is missing, which reacts to ''sw_Switch:on'' and executes two commands:
*Switching on the staircase light with <code>set sw_Light on</code>
*Start a timer that switches it off after one minute. So <code>define a1 at +00:01 set sw_Light off</code>.

This will look like this (and must be entered in the command field as a single line):
define n_sw_Switch_on notify sw_Switch:on
set sw_Light on;;define a1 at +00:01 set sw_Light off
When the Notify is triggered, the staircase lighting is switched on as a command, as well as the definition of a timer that switches it off a minute later.
Is it working?

[[Datei:ErsteSchritteInFhem19.png]]

Since this is quite bulky, there is a slightly simpler alternative:
define n_sw_Switch_on notify sw_Switch:on set sw_Light on;;sleep 60;;set sw_Light off

Some hardware systems also offer the command ''on-for-timer'', which can be used to write alternatively
define n_sw_Switch_on notify sw_Switch:on set sw_Light on-for-timer 60

==What's next?==
You have now been introduced to:
*Creating FHEM devices with '''define'''
*'''Events''' and the Event Monitor
*Switching Devices with '''set'''
*Modifying Devices with '''modify''', '''rename''' and '''delete'''
*Setting and editing '''Attributs'''
*Event driven actions by '''notify'''
*Time-controlled switching with '''at'''

So you know the most basic mechanisms of FHEM. Details of these commands can be found in the FHEM command reference {{Link2CmdRef}}

In the commandref you will find the description of all FHEM commands as well as the list of all device types that can be integrated in FHEM.

You will find that "real" FHEM devices look exactly like the dummy devices you have already seen here. The main difference is that you no longer have to define the available commands yourself using ''attr webCmd'', since they are already predefined by the FHEM device. And events are triggered not only when you click on the FHEM web frontend, but also when the physical device (i. e. the motion sensor or the light switch on the wall) is triggered.

Once you have paired your first devices with FHEM, look at the event monitor to see when which events will be triggered.

A more comprehensive introduction to FHEM can be found in the document [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung-mit-FHEM] (German)

The basics of the programming language Perl, which are important for FHEM, can be read in the first chapters of a Perl book or in various free online tutorials.

Have fun and success with FHEM!

[[Kategorie:HOWTOS]]

----
----
This is the english version of [[Erste Schritte in FHEM]]
* Last edit German article: {{REVISIONDAY2: Erste Schritte in FHEM}}.{{REVISIONMONTH: Erste Schritte in FHEM}}.{{REVISIONYEAR: Erste Schritte in FHEM}}
*Last edit English article: {{REVISIONDAY2: First steps in FHEM}}.{{REVISIONMONTH: First steps in FHEM}}.{{REVISIONYEAR: First steps in FHEM}}
*'''Newer''' Version is: '''{{#ifexpr: {{REVISIONTIMESTAMP: Erste Schritte in FHEM}} > {{REVISIONTIMESTAMP: First steps in FHEM}}| dt. Version|engl. Version}}'''
----
----

First steps in FHEM

2024-12-31T19:56:58Z

Afo-solar: I changed the English text according to the German version. The German version makes use of the framed "+" button, which is very useful, if you want to enter multiple commands in one run. When using the "first steps" text myself I started with the German version and switched to the English one in the end. This had the consequence that I missed section about the usage of the "+" button. Hence, in the ongoing work I wondered how one can upload batch files and used only single command lines.

This a beginners course for those starting to work with FHEM. After you have installed FHEM on your server you may reproduce all steps without any additional smart home hardware.

This guide was originally published by Ulrich Maass, who gave his permission to publish it in the FHEM wiki.

Note to editors: Everybody is welcome to improve typo, grammar and style. Content changes and extentions should be discussed with the author (e. g. on associated [[Diskussion:First_steps_in_FHEM|discussion page]]).

== First attempt ==
To start FHEM for the first time, enter in your browser's address field:
<nowiki>http://<ip-address>:8083</nowiki>
e. g. <nowiki>http://192.168.1.1:8083</nowiki>.

The FHEM homepage is displayed:

[[Datei:ErsteSchritteInFhem01.png|border]]

* At the top of the screen you can see the white ''command line'' where you can enter commands.
* The first menu item is the ''Save config'' button, which saves changes so that they are still available even after a restart.
* Furthermore, there are already the rooms ''Unsorted'' and ''Everything'' that we will soon get to know
* In the lower block there are further links, which we will also discuss later.

The ''Security Check'' note indicates that you have not yet set a password for FHEM. To set up password protection, see the FHEM command reference {{Link2CmdRef|Anker=allowed}}, which contains a description of all FHEM functions and modules. To suppress this message for now, enter the following in the command line:
attr global motd none
and confirm this change with {{Taste|Enter}} or click on the link of the same name.

[[Datei:ErsteSchritteInFhem02.png|border]]

== Creating device - define ==
The basic element of FHEM is called ''device''.Typical devices are, for example, remote controlled outlets, roller shutter motors, temperature sensors, solenoid valves etc.

But other things that at first glance wouldn't appear to be a physical device are devices: for example, the user interface of FHEM itself is a device (''"FHEMWEB"''), and there are devices without physical equipment that can be used to store a variable.

We will now create a very simple device, called ''dummy''.

A dummy device is a special object in that it does not necessarily require a corresponding physical device (physical lamp, roller shutter, solenoid valve). In this way, you can carry out these steps without any hardware, and you can go through this general introduction without having to deal with the differences between the various hardware systems. A dummy device typically looks exactly the same in the FHEM interface as a FHEM device corresponding to a physical device in your hardware environment.

First, we'll create a switch. This simulates a light switch in the wall. To do this, enter the following command in the command field:
define mySwitch1 dummy

"define" is the needed FHEM command, "mySwitch1" the future name of our device, "dummy" describes its type. The words "define" and "dummy" are part of FHEM's command syntax and cannot be modified, "mySwitch1" is (more or less) arbitrary. After pressing {{Taste|Enter}} the detailed view of our new FHEM device ''mySwitch1'' is displayed.

[[Datei:ErsteSchritteInFhem03.png|border]]

{{Hinweis|Each device has exactly one "type". This type also defines the Perl command file (more precisely referred to as the "module") in which certain routines and properties are coded. Since our device is of type ''dummy'', FHEM knows that the routines and properties are located in module 98_dummy. pm. (The number 98 used to have a meaning, but today this is no longer the case, though it is still used for historical reasons.)}}

Devices have a "state" that changes over time and that FHEM records. For example, a window is opened, a roller shutter curtain is closed and a radio socket is alive. A state does not have to contain exactly one variable (window either "open" or "closed"), a state can also be described by several variables (the state of a raspberry system, device-type sysmon, includes for example the CPU frequency, the CPU temperature, the workload and much more).

The device status in FHEM consists of three blocks of values, called ''Internals'', ''Attributes'' and ''Readings''. It would be too early to go into the meaning of the three terms in detail, but the following remarks are important for the following steps:
* ''Internals'' store very basic information about a device. They are rarely edited directly by the user (usually only during device setup).
* ''Attributes'' control device behavior. Typically they can be changed (or even defined) by users.
* ''Readings'' have, in contrast to the values of the other two blocks, a timestamp. Usually they are measured values of your device.

It may be confusing for beginners that there could be Internals and Readings with the same names (e.g. STATE and state). However, Perl is case sensitive!

{{Hinweis|Block '''''Internals''''' always shows basic characteristics of a FHEM device:
*'''''NAME:''''' device name assigned by the user
*'''''TYPE:''''' device type of FHEM device, here: ''dummy''
*'''''STATE:''''' device state shown in all summaries. Since there was no assignment till now it is initially '''''???'''''.}}

== Creating rooms ==

Let's do a step forward and arrange our devices in rooms. You may consider it reasonable to put together devices physically (really) located in one room into a FHEM room. So you can find in "''bedroom''" appropriate devices like "''shutter''", "''time switch''" and "''radio set''". You may decide other assignments: put all measuring devices like thermometers, electric meters and hygrometers in one (possibly only virtually and not physically existing) room "''measuring devices''". Name of a room is arbitrary.

To achieve this you have to add to all devices which your room should contain an "Attribute" (see above). Name of the attribute is "room" and it should get as its value the room name. Let's try it with our room ''dummy''. Use command
attr mySwitch1 room Training
and finish input with {{Taste|Enter}}).

With this command you have added to device ''mySwitch1'' Attribute ''room'' with value ''Training''. Again, ''attr'', ''mySwitch1'' (while referencing to an existing object's name) and ''room'' are part of FHEM's command syntax and are unalterable, ''Training'' is arbitrary.

Now ''mySwitch1'' belongs to room ''Training''. Due to this assignment room appears in navigation bar on the left hand side in room's block. Try to click at room ''Training''.

[[Datei:ErsteSchritteInFhem04.png]]

FHEM will show all devices belonging to this room. Until now we have only one device: ''mySwitch1'' - our dummy.

Beside device name always device status is on display, we still get ''???''. Clicking at name ''mySwitch1'' you will return to its detailed view.

Our dummy is shown in a block with (type) label ''dummy''. You may change label as well introducing a further attribute "''group''" and assigning to it (arbitrary as well) name: groups order devices inside a room.

'''Note''': If you want to delete a room, you may do so by removing all devices from this room. In our example of room ''Training'' you have to delete attribute room in all devices of room ''Training''. Room ''Training'' will disappear by itself.

== Creating switching commands ==
Now we want to add on/off buttons to "mySwitch1":
attr mySwitch1 webCmd on:off

Again we use an attribute named webCmd with values on:off, we want to add to device "mySwitch1". Instead of entering mentioned above command into command line field you may choose desired attribute (in this case: '''''webCmd''''') in lower part of detail view and enter needed values into text field right next, in this case '''''on:off'''''. Complete your input with a click on button {{Taste|attr}}.

[[Datei:ErsteSchritteInFhem05.png]]

Now let's click again on room ''Training''.

You may see, that due to attribute added in last step in room view switch buttons for ''on'' and ''off'' have appeared.

[[Datei:ErsteSchritteInFhem06.png]]
Experimentally click on ''on'' and ''off'': instead of ''???'' you got so far you may find a bulb symbol showing current state.

Clicking on device name ''mySwitch1'' you change back to detail view and may see in block ''Internals'' current state ''STATE'' - being shown in room view as an icon (bulb).

[[Datei:ErsteSchritteInFhem07.png]]

In detail view you can see a new block ''Readings'' as well.

Please switch off ''mySwitch1'' once again. Pay attention to readings: next to internal ''STATE'' you may find a reading of same name (see above: Perl distinguishes lower and upper case), but equipped with a timestamp. Check reading ''state'' for updating at value and timestamp.

== Event monitor ==

Please, open in your browser another window with FHEM and in FHEM its '''[[Event monitor]]'''. The shortest way is to right-click on ''Event monitor'' and to select from the local menu "Open in new window". Place windows in such a way, that you can follow event monitor and operate your "mySwitch1" at once. Using Windows 7 or newer simply activate one window and press {{Taste|Windows}}+{{Taste|Pfeil rechts}}, followed by activating second window and pressing {{Taste|Windows}}+{{Taste|Pfeil links}}.

[[Datei:ErsteSchritteInFhem08.png]]

Devices communicate via events. One device sends an event to FHEM and FHEM distributes this event to all devices. Devices decide whether to react or not and if yes - how. Let's have a closer look at this.

Switching ''mySwitch1'' FHEM generates an event. With every actuation of the switch yet another event appears in ''Event monitor''. Please look what happens when you consecutively click twice on ''on''.

Events always consist of a timestamp followed by the type of the triggering device (in this case: ''dummy''), name of the triggering device (in this case: ''mySwitch1'') as well as triggered command (in this case: ''on'' or ''off'').

FHEM devices like remotes or remote-controlled wall switches, which trigger physical events, generate events in FHEM with every keypress in device itself or click on associated FHEM device.

Understanding events, their structure and operation is crucial - we will frequently need them below.

== Operating devices - set ==

So you have learned to switch ''mySwitch1'' clicking at ''on'' or ''off''. Alternatively you can use command line entering instructions there.

So please, enter in command line field <code>set mySwitch1 on</code> or <code>set mySwitch1 off</code> and confirm this with button {{Taste|Enter}}. Switching status will change accordingly as well and an Event will be triggered. By the way, we will frequently use command ''set'' in future.

Preparing further tests we now create a new device '''''myLamp1''''' that we later on want to control with '''''mySwitch1'''''.
define myLamp1 dummy

Since ''myLamp1'' is a lamp - an actor - it won't get buttons for ''on'' or ''off''.

Lamp should be located in room ''Training''. You might set this assignment via command line, like shown above. But this time we will use computer mouse...

Until now ''myLamp1'' has no room assignment, so it appears in room ''Unsorted''. Switch over to this room and click at name ''myLamp1'' getting to detail view.

In the lower part we can set attribute assignments.

Attribute ''room'' is already selected (as default). When you click at text field next to ''room'', a dialog box opens that contains all rooms FHEM knows so far. You may select one ore more checkboxes and assign this or these rooms to device. Now select only room ''Training'' and confirm selection with button {{Taste|OK}}. Selected room will be transferred into text field and it remains only to click at button {{Taste|attr}} to activate assignment.

[[Datei:ErsteSchritteInFhem09.png]]

Now change back to room ''Training'' and you will see both devices:

[[Datei:ErsteSchritteInFhem10.png]]

== Event trigger - notify ==
Now we will enable FHEM to react to an event of ''mySwitch1'': Every time ''mySwitch1'' is triggering event with command ''on'' we want to switch on ''myLamp1''.

For it FHEM uses a "notify". Defining syntax looks like
define <NAME> notify <REGEXP> <command>

* Name '''<NAME>''' will help us to find this FHEM device and display its properties. This time we name the device ''n_mySwitch1_on'' - ''n_'' for marking it a notify, followed by the name of triggering device and triggering command. Such a name may seem too complicated but it is very useful when working with a whole bunch of notifies. You may name it if desired ''n1'' or ''John Doe''. Device names may consist of characters '''a-z''', '''A-Z''', '''0-9''', '''_ (underscore)''' and '''. (period)''' with a period not at first position. In perl and therefore in FHEM period has a special meaning, so avoid if possible periods in device names.
*'''<REGEXP>''' stands for "regular expression" and describes a condition for raising notify. We will meet regular expressions in perl and FHEM frequently. They are used to describe syntactical characteristics of strings, e. g. whether a string contains a given word or not, whether digits are in our string and much more. Whenever in FHEM an event raises for every notify runs a check for regexp matching. In our case ''mySwitch1'' raises an event with command ''on''. To "catch" this event and react to it we have notation <code>mySwitch1:on</code>. In future you will have many more moments to deal with regexps in detail. :)
*'''<command>''' tells what to do. In our case: <code>set myLamp1 on</code>.

So our notify looks like
define n_mySwitch1_on notify mySwitch1:on set myLamp1 on

After you have entered this in command field followed by {{Taste|Enter}}, you will see again detail view of the new FHEM notify device (see TYPE).

[[Datei:ErsteSchritteInFhem11.png]]

In block ''Internals'' you can find definition '''DEF'''. Here you see all text you have entered in event definition after the word "notify" (device type). So you can see ''<regexp>'' and ''<command>''.
{{Hinweis|In Block '''''Probably associated with''''' you can find all FHEM devices associated with this notify. Devices are listed as clickable device names, so you can jump over with only one click to detail view of the respective device.}}

Please assign notify to room ''Training'' (find in the lower part attribute ''room'' and choose correct room followed by a click at ''attr'').

So clicking in FHEM's main menu at ''Training'' you will get our three FHEM devices.

[[Datei:ErsteSchritteInFhem12.png]]

{{Hinweis|Usally a notify wouldn't be assigned to a room since it shouldn't be visible to user later on. We will do it anyway for our training purposes.}}

Now switch ''mySwitch1'' to ''on'' - ''myLamp1'' will be switched too. It seems that it works only at first time, but checking event monitor or looking in ''myLamp1'''s detail view at timestamp of last state change you can notice that it executes every time.

To get it working for switching off too we define a second notify:
define n_mySwitch1_off notify mySwitch1:off set myLamp1 off

Does it work as expected?

Doubtless you dislike defining an own notify for every command a device should raise. You can get it easier.

Instead of
define n_mySwitch1_on notify mySwitch1:on set myLamp1 on
define n_mySwitch1_off notify mySwitch1:off set myLamp1 off
we define
define n_mySwitch1 notify mySwitch1 set myLamp1 '''$EVENT'''
We see that this time regexp doesn't differ events ''on'' and ''off'' of ''mySwitch1''. With an absent regexp declaration notify raises for any event with whatsoever command. In executing set command we use FHEM variable '''$EVENT''' (follow the capital notation!). This is a placeholder for the command taken over from the raising event. Having from ''mySwitch1'' an ''on'', '''$EVENT''' will stand for value ''on'' too, accordingly for ''off'' and any other command.

== Deleting or disabling devices – delete, disable ==
Looking at Event Monitor you see that after activation of ''mySwitch1'' command for ''myLamp1'' is executed twice. The reason is, that any event of ''mySwitch1'' is caught by two notifies - by the "old" notify as well as by the new one. To avoid this we should get rid of the old one. For that purpose we have two choices.

#'''Delete''' a notify with command <code>delete <name></code>, e. g. with <code>delete n_mySwitch1_on</code>. By the way, command <code>delete</code> works with any object in FHEM. So you can delete this way "real" devices too.
#'''Deactivate''' a notify, using attribute ''disable''. You can assign it in detail view of the related notify. (Choose the attribute ''disable'' in drop-down menu next to {{Taste|attr}} in lower part and choose value ''1'' with a following click at {{Taste|attr}}.) Or enter in command line: <code>attr n_mySwitch1_off disable 1</code>.

== Save Config ==
Whenever you are satisfied with the current state of your FHEM configuration, click on '''''Save config''''' in the top left corner of the FHEM menu or enter the command <code>save</code> in the command field followed by {{Taste|Enter}}. Your configuration is now saved. If you do not do this, all changes will be lost after the next FHEM restart. FHEM therefore reminds you of unsaved changes with a red question mark next to '''''Save config'''''.

== Modifying existing devices – modify ==

We now create a second lamp, which should also be switched by our ''mySwitch1'' and our Notify. The new lamp is created by entering the following in the command field:
define myLamp2 dummy

With several clicks in the detail screen of ''myLamp2'' you can also assign them to the room Training and assign buttons for ''on'' and ''off'' via the ''webCmd'' attribute.

[[Datei:ErsteSchritteInFhem13.png]]

Now we adjust the Notify ''n_mySwitch1''. To do this, navigate to the Notify detail screen: Switch to the ''Training'' room and click on the name of ''n_mySwitch1''.

In the detail screen there is the line ''DEF'', which we have already looked at before. If you click on the word ''DEF'', you can edit the definition of an FHEM object.

{{Hinweis|The ''DEF'' field displays only the part of the definition that followed the object type, i. e. notify, as you created this notification. Here you will find the regex to which the Notify reacts, then the command to be executed after an empty space. For the sake of readability, the entire define statement is always shown below, even if it is not completely visible in the ''DEF'' field.}}

We change here from
define n_mySwitch1 notify mySwitch1 set myLamp1 $EVENT
to
define n_mySwitch1 notify mySwitch1 set myLamp1,myLamp2 $EVENT

[[Datei:ErsteSchritteInFhem14.png]]

To finish editing click on the ''''modify <name>'''' button, i. e. {{Taste|modify n_mySwitch1}}. If you check the details in the detail screen, you will see that the ''DEF''inition of the notify has been adjusted.

[[Datei:ErsteSchritteInFhem14B.png]]

Note again that in the detail screen below under ''Probably associated with'' the switched lamps will appear in the lower section of the detail screen - this will often be useful.

{{Hinweis|By the way, you can use the link ''''Device specific help'''' to view the complete help text for your device type from commandref, i. e. the help text for ''notify''. This link is often helpful, especially at the beginning.}}

Now you can test whether a click on ''mySwitch1'' really switches both lamps. Take a look at the events in a separate window with the Event Monitor.

[[Datei:ErsteSchritteInFhem15.png]]

== Switching a couple of devices at once ==

For switching several devices can therefore be used
set <device1>,<device2> on

An alternative spelling for it is
set <device1> on; set <device2> on

Also a combination is possible:
set <device1>,<device2> on; set <device3> off

Even within a notify (or other FHEM commands) you can list several commands, but here is one thing to note:
define n1 notify mySwitch1:on set myLamp1 on;set myLamp2 off
The commands are separated by a semicolon. Effect is: The notify switches myLamp1 whenever mySwitch1 sends the event on. The next command in this line is ''set myLamp2 off''. This is processed '''immediately''' when the above-mentioned command line is entered. It switches myLamp2 immediately, myLamp1 only after the mySwitch1 event.

If the second command ''set myLamp2 off'' should also be executed after the event, a double semicolon must be used:
define n1 notify mySwitch1:on set myLamp1 on;;set myLamp2 off

The combined variant could look like this:
define n1 notify mySwitch1:on set myLamp1 on;;set myLamp2 off;set myLampe3 on
This command line would switch myLamp3 immediately, but only after the mySwitch1 event myLamp1 and myLamp2 switch.

== Renaming devices ==

Finally we want to rename (for the exercise) another device: '''''myLamp2''''' should be '''''myStandardLamp'''''. For this we use
rename <oldName> <newName>

It should be noted that related notify statements are '''not''' updated automatically. So, before renaming, note the ''Probably associated with'' list at the bottom of the detail screen so that you do not forget any of your Notify during the following adjustment.

So enter in the command box
rename myLamp2 myStandardLamp
and then adjust ''n_mySwitch1'' by customizing the definition on its detail screen in the 'DEF' section.

After the change, the Notify must be
define n_mySwitch1 notify mySwitch1 set myLamp1,myStandardLamp $EVENT

[[Datei:ErsteSchritteInFhem16.png]]

== Scheduler - at ==
The next step is to set up a time control.
First of all, we want to ensure that ''myLamp1'' is switched off after one minute, such as a staircase light.

{{Hinweis|To see the effect, first switch ''myLamp1'' to ''on''.}}

The FHEM device type ''at'' is available for time control. The command structure is
define <name> at <timespec> <command>
'''<name>''' and '''<command>''' have the same function here as with notify. New here is only '''<timespec>''' (time specification), so the time specification. This is done in the notation ''HH:MM:SS'' or ''HH:MM''.

To turn off '''''myLamp1''''' so '''in one minute''', create the following ''at'':
define a_myLamp1 at +00:01:00 set myLamp1 off

[[Datei:ErsteSchritteInFhem17.png]]

Try it.
Will ''myLamp1'' be turned off after one minute?
Is an event generated during this process?

If you want to see the detail view of the ''at'', you have to hurry up: After a single execution, the ''at'' is automatically deleted. If FHEM was faster, you can create it again and specify a longer period of time if necessary. :-)

With <timespec> you can omit the seconds and just write HH:MM. There are also several variants:
{|class="wikitable"
|+Variants of time specifications for ''at''
|-
!notation
!explanation
|-
|style="text-align: right;"|+00:02:00
|In two minutes; single execution
|-
|style="text-align: right;"|00:02:00
|At two minutes past midnight, i.e. at 00:02 and 0 seconds; one-time execution
|-
|style="text-align: right;"|*00:02:00
|Daily at 00:02
|-
|style="text-align: right;"|+*00:02:00
|Every 2 minutes
|-
|style="text-align: right;"|+*{3}00:02
|Three times, every two minutes
|-
|style="text-align: right;"|*{3}00:02
|Three times at 00:02
|-
|style="text-align: right;"|*{sunset_rel()}
|Daily at sunset
|-
|style="text-align: right;"|*{sunrise(+120)}
|2 minutes (120 seconds) daily after sunrise
|}
*By specifying '''*''' a permanent repetition is defined. The repetitions continue until the ''at'' is deleted or disabled.
*By specifying '''+''' the specified time is no longer interpreted as an absolute time, but as a timer, after how many hours:minutes:seconds the command is executed.
*By specifying '''''{n}''''' the ''at'' will only be run n times.
*The functions '''''{sunset_rel()}''''' and '''''{sunrise()}''''' return the appropriate time. This is repeated daily by specifying '''''*'''''. The curly braces indicate that FHEM directly executes the contents of these braces as perl functions.

For example, to switch off the garden lighting every day at sunrise, define something like
define a_gardenLight_morning_off at *{sunrise()} set gardenLight off

[[Datei:ErsteSchritteInFhem18.png]]

In the detail screen of an ''at'' the time of the next execution is displayed in the ''STATE''.

This info also appears in the room view if you show the ''at'' there:

[[Datei:ErsteSchritteInFhem18B.png]]

== Event-driven timer start - notify und at ==
{{Randnotiz|RNText='''Time and Event Control with DOIF'''
Since the release of the original article in early 2014, another way of time and event control has been introduced. See: {{Link2CmdRef|Anker=DOIF}} for DOIF}}
As a last exercise we want to combine a ''notify'' and an ''at''. The timer should now not start when you enter the command in the command field, but when an event occurs.

[[Datei:GotoRAW-Import firststeps.PNG|thumb|left|300px]]For this purpose, we create a Stairwell: create the Dummy-Devices ''sw_Switch'' and ''sw_Light'' in the ''room Stairwell''. In order to enter the following commands on one piece, click the framed "+" icon next to the command line (only available in the default Style f18 - please note this article [[Import von Code Snippets|Import-of-Code-Snippets]]), add the following lines with copy&paste to the dialog box that appears and press {{Taste|Execute}}:
define sw_Switch dummy
attr sw_Switch room Stairwell
attr sw_Switch webCmd on
define sw_Light dummy
attr sw_Light room Stairwell
[[Datei:RAW-Import firststeps.PNG]]

Then you can close the dialog or enter the following commands. Note that with ''Execute'' all statements from the dialog box are executed, which may lead to error messages e.g. if a device has already been defined before. Lines with commands that have already been adopted into the configuration can therefore confidently delete to avoid such effects.

Now the Notify is missing, which reacts to ''sw_Switch:on'' and executes two commands:
*Switching on the staircase light with <code>set sw_Light on</code>
*Start a timer that switches it off after one minute. So <code>define a1 at +00:01 set sw_Light off</code>.

This will look like this (and must be entered in the command field as a single line):
define n_sw_Switch_on notify sw_Switch:on
set sw_Light on;;define a1 at +00:01 set sw_Light off
When the Notify is triggered, the staircase lighting is switched on as a command, as well as the definition of a timer that switches it off a minute later.
Is it working?

[[Datei:ErsteSchritteInFhem19.png]]

Since this is quite bulky, there is a slightly simpler alternative:
define n_sw_Switch_on notify sw_Switch:on set sw_Light on;;sleep 60;;set sw_Light off

Some hardware systems also offer the command ''on-for-timer'', which can be used to write alternatively
define n_sw_Switch_on notify sw_Switch:on set sw_Light on-for-timer 60

==What's next?==
You have now been introduced to:
*Creating FHEM devices with '''define'''
*'''Events''' and the Event Monitor
*Switching Devices with '''set'''
*Modifying Devices with '''modify''', '''rename''' and '''delete'''
*Setting and editing '''Attributs'''
*Event driven actions by '''notify'''
*Time-controlled switching with '''at'''

So you know the most basic mechanisms of FHEM. Details of these commands can be found in the FHEM command reference {{Link2CmdRef}}

In the commandref you will find the description of all FHEM commands as well as the list of all device types that can be integrated in FHEM.

You will find that "real" FHEM devices look exactly like the dummy devices you have already seen here. The main difference is that you no longer have to define the available commands yourself using ''attr webCmd'', since they are already predefined by the FHEM device. And events are triggered not only when you click on the FHEM web frontend, but also when the physical device (i. e. the motion sensor or the light switch on the wall) is triggered.

Once you have paired your first devices with FHEM, look at the event monitor to see when which events will be triggered.

A more comprehensive introduction to FHEM can be found in the document [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung-mit-FHEM] (German)

The basics of the programming language Perl, which are important for FHEM, can be read in the first chapters of a Perl book or in various free online tutorials.

Have fun and success with FHEM!

[[Kategorie:HOWTOS]]

----
----
This is the english version of [[Erste Schritte in FHEM]]
* Last edit German article: {{REVISIONDAY2: Erste Schritte in FHEM}}.{{REVISIONMONTH: Erste Schritte in FHEM}}.{{REVISIONYEAR: Erste Schritte in FHEM}}
*Last edit English article: {{REVISIONDAY2: First steps in FHEM}}.{{REVISIONMONTH: First steps in FHEM}}.{{REVISIONYEAR: First steps in FHEM}}
*'''Newer''' Version is: '''{{#ifexpr: {{REVISIONTIMESTAMP: Erste Schritte in FHEM}} > {{REVISIONTIMESTAMP: First steps in FHEM}}| dt. Version|engl. Version}}'''
----
----

First steps in FHEM

2024-12-05T08:11:50Z

Afo-solar: To set the attribute "disable" in detail view, one has to chose the attribute in a drop-down menu. This point is clarified by the submitted changes

This a beginners course for those starting to work with FHEM. After you have installed FHEM on your server you may reproduce all steps without any additional smart home hardware.

This guide was originally published by Ulrich Maass, who gave his permission to publish it in the FHEM wiki.

Note to editors: Everybody is welcome to improve typo, grammar and style. Content changes and extentions should be discussed with the author (e. g. on associated [[Diskussion:First_steps_in_FHEM|discussion page]]).

== First attempt ==
To start FHEM for the first time, enter in your browser's address field:
<nowiki>http://<ip-address>:8083</nowiki>
e. g. <nowiki>http://192.168.1.1:8083</nowiki>.

The FHEM homepage is displayed:

[[Datei:ErsteSchritteInFhem01.png|border]]

* At the top of the screen you can see the white ''command line'' where you can enter commands.
* The first menu item is the ''Save config'' button, which saves changes so that they are still available even after a restart.
* Furthermore, there are already the rooms ''Unsorted'' and ''Everything'' that we will soon get to know
* In the lower block there are further links, which we will also discuss later.

The ''Security Check'' note indicates that you have not yet set a password for FHEM. To set up password protection, see the FHEM command reference {{Link2CmdRef|Anker=allowed}}, which contains a description of all FHEM functions and modules. To suppress this message for now, enter the following in the command line:
attr global motd none
and confirm this change with {{Taste|Enter}} or click on the link of the same name.

[[Datei:ErsteSchritteInFhem02.png|border]]

== Creating device - define ==
The basic element of FHEM is called ''device''.Typical devices are, for example, remote controlled outlets, roller shutter motors, temperature sensors, solenoid valves etc.

But other things that at first glance wouldn't appear to be a physical device are devices: for example, the user interface of FHEM itself is a device (''"FHEMWEB"''), and there are devices without physical equipment that can be used to store a variable.

We will now create a very simple device, called ''dummy''.

A dummy device is a special object in that it does not necessarily require a corresponding physical device (physical lamp, roller shutter, solenoid valve). In this way, you can carry out these steps without any hardware, and you can go through this general introduction without having to deal with the differences between the various hardware systems. A dummy device typically looks exactly the same in the FHEM interface as a FHEM device corresponding to a physical device in your hardware environment.

First, we'll create a switch. This simulates a light switch in the wall. To do this, enter the following command in the command field:
define mySwitch1 dummy

"define" is the needed FHEM command, "mySwitch1" the future name of our device, "dummy" describes its type. The words "define" and "dummy" are part of FHEM's command syntax and cannot be modified, "mySwitch1" is (more or less) arbitrary. After pressing {{Taste|Enter}} the detailed view of our new FHEM device ''mySwitch1'' is displayed.

[[Datei:ErsteSchritteInFhem03.png|border]]

{{Hinweis|Each device has exactly one "type". This type also defines the Perl command file (more precisely referred to as the "module") in which certain routines and properties are coded. Since our device is of type ''dummy'', FHEM knows that the routines and properties are located in module 98_dummy. pm. (The number 98 used to have a meaning, but today this is no longer the case, though it is still used for historical reasons.)}}

Devices have a "state" that changes over time and that FHEM records. For example, a window is opened, a roller shutter curtain is closed and a radio socket is alive. A state does not have to contain exactly one variable (window either "open" or "closed"), a state can also be described by several variables (the state of a raspberry system, device-type sysmon, includes for example the CPU frequency, the CPU temperature, the workload and much more).

The device status in FHEM consists of three blocks of values, called ''Internals'', ''Attributes'' and ''Readings''. It would be too early to go into the meaning of the three terms in detail, but the following remarks are important for the following steps:
* ''Internals'' store very basic information about a device. They are rarely edited directly by the user (usually only during device setup).
* ''Attributes'' control device behavior. Typically they can be changed (or even defined) by users.
* ''Readings'' have, in contrast to the values of the other two blocks, a timestamp. Usually they are measured values of your device.

It may be confusing for beginners that there could be Internals and Readings with the same names (e.g. STATE and state). However, Perl is case sensitive!

{{Hinweis|Block '''''Internals''''' always shows basic characteristics of a FHEM device:
*'''''NAME:''''' device name assigned by the user
*'''''TYPE:''''' device type of FHEM device, here: ''dummy''
*'''''STATE:''''' device state shown in all summaries. Since there was no assignment till now it is initially '''''???'''''.}}

== Creating rooms ==

Let's do a step forward and arrange our devices in rooms. You may consider it reasonable to put together devices physically (really) located in one room into a FHEM room. So you can find in "''bedroom''" appropriate devices like "''shutter''", "''time switch''" and "''radio set''". You may decide other assignments: put all measuring devices like thermometers, electric meters and hygrometers in one (possibly only virtually and not physically existing) room "''measuring devices''". Name of a room is arbitrary.

To achieve this you have to add to all devices which your room should contain an "Attribute" (see above). Name of the attribute is "room" and it should get as its value the room name. Let's try it with our room ''dummy''. Use command
attr mySwitch1 room Training
and finish input with {{Taste|Enter}}).

With this command you have added to device ''mySwitch1'' Attribute ''room'' with value ''Training''. Again, ''attr'', ''mySwitch1'' (while referencing to an existing object's name) and ''room'' are part of FHEM's command syntax and are unalterable, ''Training'' is arbitrary.

Now ''mySwitch1'' belongs to room ''Training''. Due to this assignment room appears in navigation bar on the left hand side in room's block. Try to click at room ''Training''.

[[Datei:ErsteSchritteInFhem04.png]]

FHEM will show all devices belonging to this room. Until now we have only one device: ''mySwitch1'' - our dummy.

Beside device name always device status is on display, we still get ''???''. Clicking at name ''mySwitch1'' you will return to its detailed view.

Our dummy is shown in a block with (type) label ''dummy''. You may change label as well introducing a further attribute "''group''" and assigning to it (arbitrary as well) name: groups order devices inside a room.

'''Note''': If you want to delete a room, you may do so by removing all devices from this room. In our example of room ''Training'' you have to delete attribute room in all devices of room ''Training''. Room ''Training'' will disappear by itself.

== Creating switching commands ==
Now we want to add on/off buttons to "mySwitch1":
attr mySwitch1 webCmd on:off

Again we use an attribute named webCmd with values on:off, we want to add to device "mySwitch1". Instead of entering mentioned above command into command line field you may choose desired attribute (in this case: '''''webCmd''''') in lower part of detail view and enter needed values into text field right next, in this case '''''on:off'''''. Complete your input with a click on button {{Taste|attr}}.

[[Datei:ErsteSchritteInFhem05.png]]

Now let's click again on room ''Training''.

You may see, that due to attribute added in last step in room view switch buttons for ''on'' and ''off'' have appeared.

[[Datei:ErsteSchritteInFhem06.png]]
Experimentally click on ''on'' and ''off'': instead of ''???'' you got so far you may find a bulb symbol showing current state.

Clicking on device name ''mySwitch1'' you change back to detail view and may see in block ''Internals'' current state ''STATE'' - being shown in room view as an icon (bulb).

[[Datei:ErsteSchritteInFhem07.png]]

In detail view you can see a new block ''Readings'' as well.

Please switch off ''mySwitch1'' once again. Pay attention to readings: next to internal ''STATE'' you may find a reading of same name (see above: Perl distinguishes lower and upper case), but equipped with a timestamp. Check reading ''state'' for updating at value and timestamp.

== Event monitor ==

Please, open in your browser another window with FHEM and in FHEM its '''[[Event monitor]]'''. The shortest way is to right-click on ''Event monitor'' and to select from the local menu "Open in new window". Place windows in such a way, that you can follow event monitor and operate your "mySwitch1" at once. Using Windows 7 or newer simply activate one window and press {{Taste|Windows}}+{{Taste|Pfeil rechts}}, followed by activating second window and pressing {{Taste|Windows}}+{{Taste|Pfeil links}}.

[[Datei:ErsteSchritteInFhem08.png]]

Devices communicate via events. One device sends an event to FHEM and FHEM distributes this event to all devices. Devices decide whether to react or not and if yes - how. Let's have a closer look at this.

Switching ''mySwitch1'' FHEM generates an event. With every actuation of the switch yet another event appears in ''Event monitor''. Please look what happens when you consecutively click twice on ''on''.

Events always consist of a timestamp followed by the type of the triggering device (in this case: ''dummy''), name of the triggering device (in this case: ''mySwitch1'') as well as triggered command (in this case: ''on'' or ''off'').

FHEM devices like remotes or remote-controlled wall switches, which trigger physical events, generate events in FHEM with every keypress in device itself or click on associated FHEM device.

Understanding events, their structure and operation is crucial - we will frequently need them below.

== Operating devices - set ==

So you have learned to switch ''mySwitch1'' clicking at ''on'' or ''off''. Alternatively you can use command line entering instructions there.

So please, enter in command line field <code>set mySwitch1 on</code> or <code>set mySwitch1 off</code> and confirm this with button {{Taste|Enter}}. Switching status will change accordingly as well and an Event will be triggered. By the way, we will frequently use command ''set'' in future.

Preparing further tests we now create a new device '''''myLamp1''''' that we later on want to control with '''''mySwitch1'''''.
define myLamp1 dummy

Since ''myLamp1'' is a lamp - an actor - it won't get buttons for ''on'' or ''off''.

Lamp should be located in room ''Training''. You might set this assignment via command line, like shown above. But this time we will use computer mouse...

Until now ''myLamp1'' has no room assignment, so it appears in room ''Unsorted''. Switch over to this room and click at name ''myLamp1'' getting to detail view.

In the lower part we can set attribute assignments.

Attribute ''room'' is already selected (as default). When you click at text field next to ''room'', a dialog box opens that contains all rooms FHEM knows so far. You may select one ore more checkboxes and assign this or these rooms to device. Now select only room ''Training'' and confirm selection with button {{Taste|OK}}. Selected room will be transferred into text field and it remains only to click at button {{Taste|attr}} to activate assignment.

[[Datei:ErsteSchritteInFhem09.png]]

Now change back to room ''Training'' and you will see both devices:

[[Datei:ErsteSchritteInFhem10.png]]

== Event trigger - notify ==
Now we will enable FHEM to react to an event of ''mySwitch1'': Every time ''mySwitch1'' is triggering event with command ''on'' we want to switch on ''myLamp1''.

For it FHEM uses a "notify". Defining syntax looks like
define <NAME> notify <REGEXP> <command>

* Name '''<NAME>''' will help us to find this FHEM device and display its properties. This time we name the device ''n_mySwitch1_on'' - ''n_'' for marking it a notify, followed by the name of triggering device and triggering command. Such a name may seem too complicated but it is very useful when working with a whole bunch of notifies. You may name it if desired ''n1'' or ''John Doe''. Device names may consist of characters '''a-z''', '''A-Z''', '''0-9''', '''_ (underscore)''' and '''. (period)''' with a period not at first position. In perl and therefore in FHEM period has a special meaning, so avoid if possible periods in device names.
*'''<REGEXP>''' stands for "regular expression" and describes a condition for raising notify. We will meet regular expressions in perl and FHEM frequently. They are used to describe syntactical characteristics of strings, e. g. whether a string contains a given word or not, whether digits are in our string and much more. Whenever in FHEM an event raises for every notify runs a check for regexp matching. In our case ''mySwitch1'' raises an event with command ''on''. To "catch" this event and react to it we have notation <code>mySwitch1:on</code>. In future you will have many more moments to deal with regexps in detail. :)
*'''<command>''' tells what to do. In our case: <code>set myLamp1 on</code>.

So our notify looks like
define n_mySwitch1_on notify mySwitch1:on set myLamp1 on

After you have entered this in command field followed by {{Taste|Enter}}, you will see again detail view of the new FHEM notify device (see TYPE).

[[Datei:ErsteSchritteInFhem11.png]]

In block ''Internals'' you can find definition '''DEF'''. Here you see all text you have entered in event definition after the word "notify" (device type). So you can see ''<regexp>'' and ''<command>''.
{{Hinweis|In Block '''''Probably associated with''''' you can find all FHEM devices associated with this notify. Devices are listed as clickable device names, so you can jump over with only one click to detail view of the respective device.}}

Please assign notify to room ''Training'' (find in the lower part attribute ''room'' and choose correct room followed by a click at ''attr'').

So clicking in FHEM's main menu at ''Training'' you will get our three FHEM devices.

[[Datei:ErsteSchritteInFhem12.png]]

{{Hinweis|Usally a notify wouldn't be assigned to a room since it shouldn't be visible to user later on. We will do it anyway for our training purposes.}}

Now switch ''mySwitch1'' to ''on'' - ''myLamp1'' will be switched too. It seems that it works only at first time, but checking event monitor or looking in ''myLamp1'''s detail view at timestamp of last state change you can notice that it executes every time.

To get it working for switching off too we define a second notify:
define n_mySwitch1_off notify mySwitch1:off set myLamp1 off

Does it work as expected?

Doubtless you dislike defining an own notify for every command a device should raise. You can get it easier.

Instead of
define n_mySwitch1_on notify mySwitch1:on set myLamp1 on
define n_mySwitch1_off notify mySwitch1:off set myLamp1 off
we define
define n_mySwitch1 notify mySwitch1 set myLamp1 '''$EVENT'''
We see that this time regexp doesn't differ events ''on'' and ''off'' of ''mySwitch1''. With an absent regexp declaration notify raises for any event with whatsoever command. In executing set command we use FHEM variable '''$EVENT''' (follow the capital notation!). This is a placeholder for the command taken over from the raising event. Having from ''mySwitch1'' an ''on'', '''$EVENT''' will stand for value ''on'' too, accordingly for ''off'' and any other command.

== Deleting or disabling devices – delete, disable ==
Looking at Event Monitor you see that after activation of ''mySwitch1'' command for ''myLamp1'' is executed twice. The reason is, that any event of ''mySwitch1'' is caught by two notifies - by the "old" notify as well as by the new one. To avoid this we should get rid of the old one. For that purpose we have two choices.

#'''Delete''' a notify with command <code>delete <name></code>, e. g. with <code>delete n_mySwitch1_on</code>. By the way, command <code>delete</code> works with any object in FHEM. So you can delete this way "real" devices too.
#'''Deactivate''' a notify, using attribute ''disable''. You can assign it in detail view of the related notify. (Choose the attribute ''disable'' in drop-down menu next to {{Taste|attr}} in lower part and choose value ''1'' with a following click at {{Taste|attr}}.) Or enter in command line: <code>attr n_mySwitch1_off disable 1</code>.

== Save Config ==
Whenever you are satisfied with the current state of your FHEM configuration, click on '''''Save config''''' in the top left corner of the FHEM menu or enter the command <code>save</code> in the command field followed by {{Taste|Enter}}. Your configuration is now saved. If you do not do this, all changes will be lost after the next FHEM restart. FHEM therefore reminds you of unsaved changes with a red question mark next to '''''Save config'''''.

== Modifying existing devices – modify ==

We now create a second lamp, which should also be switched by our ''mySwitch1'' and our Notify. The new lamp is created by entering the following in the command field:
define myLamp2 dummy

With several clicks in the detail screen of ''myLamp2'' you can also assign them to the room Training and assign buttons for ''on'' and ''off'' via the ''webCmd'' attribute.

[[Datei:ErsteSchritteInFhem13.png]]

Now we adjust the Notify ''n_mySwitch1''. To do this, navigate to the Notify detail screen: Switch to the ''Training'' room and click on the name of ''n_mySwitch1''.

In the detail screen there is the line ''DEF'', which we have already looked at before. If you click on the word ''DEF'', you can edit the definition of an FHEM object.

{{Hinweis|The ''DEF'' field displays only the part of the definition that followed the object type, i. e. notify, as you created this notification. Here you will find the regex to which the Notify reacts, then the command to be executed after an empty space. For the sake of readability, the entire define statement is always shown below, even if it is not completely visible in the ''DEF'' field.}}

We change here from
define n_mySwitch1 notify mySwitch1 set myLamp1 $EVENT
to
define n_mySwitch1 notify mySwitch1 set myLamp1,myLamp2 $EVENT

[[Datei:ErsteSchritteInFhem14.png]]

To finish editing click on the ''''modify <name>'''' button, i. e. {{Taste|modify n_mySwitch1}}. If you check the details in the detail screen, you will see that the ''DEF''inition of the notify has been adjusted.

[[Datei:ErsteSchritteInFhem14B.png]]

Note again that in the detail screen below under ''Probably associated with'' the switched lamps will appear in the lower section of the detail screen - this will often be useful.

{{Hinweis|By the way, you can use the link ''''Device specific help'''' to view the complete help text for your device type from commandref, i. e. the help text for ''notify''. This link is often helpful, especially at the beginning.}}

Now you can test whether a click on ''mySwitch1'' really switches both lamps. Take a look at the events in a separate window with the Event Monitor.

[[Datei:ErsteSchritteInFhem15.png]]

== Switching a couple of devices at once ==

For switching several devices can therefore be used
set <device1>,<device2> on

An alternative spelling for it is
set <device1> on; set <device2> on

Also a combination is possible:
set <device1>,<device2> on; set <device3> off

Even within a notify (or other FHEM commands) you can list several commands, but here is one thing to note:
define n1 notify mySwitch1:on set myLamp1 on;set myLamp2 off
The commands are separated by a semicolon. Effect is: The notify switches myLamp1 whenever mySwitch1 sends the event on. The next command in this line is ''set myLamp2 off''. This is processed '''immediately''' when the above-mentioned command line is entered. It switches myLamp2 immediately, myLamp1 only after the mySwitch1 event.

If the second command ''set myLamp2 off'' should also be executed after the event, a double semicolon must be used:
define n1 notify mySwitch1:on set myLamp1 on;;set myLamp2 off

The combined variant could look like this:
define n1 notify mySwitch1:on set myLamp1 on;;set myLamp2 off;set myLampe3 on
This command line would switch myLamp3 immediately, but only after the mySwitch1 event myLamp1 and myLamp2 switch.

== Renaming devices ==

Finally we want to rename (for the exercise) another device: '''''myLamp2''''' should be '''''myStandardLamp'''''. For this we use
rename <oldName> <newName>

It should be noted that related notify statements are '''not''' updated automatically. So, before renaming, note the ''Probably associated with'' list at the bottom of the detail screen so that you do not forget any of your Notify during the following adjustment.

So enter in the command box
rename myLamp2 myStandardLamp
and then adjust ''n_mySwitch1'' by customizing the definition on its detail screen in the 'DEF' section.

After the change, the Notify must be
define n_mySwitch1 notify mySwitch1 set myLamp1,myStandardLamp $EVENT

[[Datei:ErsteSchritteInFhem16.png]]

== Scheduler - at ==
The next step is to set up a time control.
First of all, we want to ensure that ''myLamp1'' is switched off after one minute, such as a staircase light.

{{Hinweis|To see the effect, first switch ''myLamp1'' to ''on''.}}

The FHEM device type ''at'' is available for time control. The command structure is
define <name> at <timespec> <command>
'''<name>''' and '''<command>''' have the same function here as with notify. New here is only '''<timespec>''' (time specification), so the time specification. This is done in the notation ''HH:MM:SS'' or ''HH:MM''.

To turn off '''''myLamp1''''' so '''in one minute''', create the following ''at'':
define a_myLamp1 at +00:01:00 set myLamp1 off

[[Datei:ErsteSchritteInFhem17.png]]

Try it.
Will ''myLamp1'' be turned off after one minute?
Is an event generated during this process?

If you want to see the detail view of the ''at'', you have to hurry up: After a single execution, the ''at'' is automatically deleted. If FHEM was faster, you can create it again and specify a longer period of time if necessary. :-)

With <timespec> you can omit the seconds and just write HH:MM. There are also several variants:
{|class="wikitable"
|+Variants of time specifications for ''at''
|-
!notation
!explanation
|-
|style="text-align: right;"|+00:02:00
|In two minutes; single execution
|-
|style="text-align: right;"|00:02:00
|At two minutes past midnight, i.e. at 00:02 and 0 seconds; one-time execution
|-
|style="text-align: right;"|*00:02:00
|Daily at 00:02
|-
|style="text-align: right;"|+*00:02:00
|Every 2 minutes
|-
|style="text-align: right;"|+*{3}00:02
|Three times, every two minutes
|-
|style="text-align: right;"|*{3}00:02
|Three times at 00:02
|-
|style="text-align: right;"|*{sunset_rel()}
|Daily at sunset
|-
|style="text-align: right;"|*{sunrise(+120)}
|2 minutes (120 seconds) daily after sunrise
|}
*By specifying '''*''' a permanent repetition is defined. The repetitions continue until the ''at'' is deleted or disabled.
*By specifying '''+''' the specified time is no longer interpreted as an absolute time, but as a timer, after how many hours:minutes:seconds the command is executed.
*By specifying '''''{n}''''' the ''at'' will only be run n times.
*The functions '''''{sunset_rel()}''''' and '''''{sunrise()}''''' return the appropriate time. This is repeated daily by specifying '''''*'''''. The curly braces indicate that FHEM directly executes the contents of these braces as perl functions.

For example, to switch off the garden lighting every day at sunrise, define something like
define a_gardenLight_morning_off at *{sunrise()} set gardenLight off

[[Datei:ErsteSchritteInFhem18.png]]

In the detail screen of an ''at'' the time of the next execution is displayed in the ''STATE''.

This info also appears in the room view if you show the ''at'' there:

[[Datei:ErsteSchritteInFhem18B.png]]

== Event-driven timer start - notify und at ==
{{Randnotiz|RNText='''Time and Event Control with DOIF'''
Since the release of the original article in early 2014, another way of time and event control has been introduced. See: {{Link2CmdRef|Anker=DOIF}} for DOIF}}
As a last exercise we want to combine a ''notify'' and an ''at''. The timer should now not start when you enter the command in the command field, but when an event occurs.

To do this we create a Stairwell: create the Dummy-Devices ''sw_Switch'' and ''sw_Light'' in the room ''Stairwell''. To create the ''Stairwell'' room assign the room to the first device via the command field, then click on all other attributes in the detail screen:
define sw_Switch dummy
attr sw_Switch room Stairwell
attr sw_Switch webCmd on
define sw_Light dummy
attr sw_Light room Stairwell

Now the Notify is missing, which reacts to ''sw_Switch:on'' and executes two commands:
*Switching on the staircase light with <code>set sw_Light on</code>
*Start a timer that switches it off after one minute. So <code>define a1 at +00:01 set sw_Light off</code>.

This will look like this (and must be entered in the command field as a single line):
define n_sw_Switch_on notify sw_Switch:on
set sw_Light on;;define a1 at +00:01 set sw_Light off
When the Notify is triggered, the staircase lighting is switched on as a command, as well as the definition of a timer that switches it off a minute later.
Is it working?

[[Datei:ErsteSchritteInFhem19.png]]

Since this is quite bulky, there is a slightly simpler alternative:
define n_sw_Switch_on notify sw_Switch:on set sw_Light on;;sleep 60;;set sw_Light off

Some hardware systems also offer the command ''on-for-timer'', which can be used to write alternatively
define n_sw_Switch_on notify sw_Switch:on set sw_Light on-for-timer 60

== What's next? ==
You have now been introduced to:
* Creating FHEM devices with '''define'''
* '''Events''' and the Event Monitor
* Switching Devices with '''set'''
* Modifying Devices with '''modify''', '''rename''' and '''delete'''
* Setting and editing '''Attributs'''
* Event driven actions by '''notify'''
* Time-controlled switching with '''at'''

So you know the most basic mechanisms of FHEM. Details of these commands can be found in the FHEM command reference {{Link2CmdRef}}

In the commandref you will find the description of all FHEM commands as well as the list of all device types that can be integrated in FHEM.

You will find that "real" FHEM devices look exactly like the dummy devices you have already seen here. The main difference is that you no longer have to define the available commands yourself using ''attr webCmd'', since they are already predefined by the FHEM device. And events are triggered not only when you click on the FHEM web frontend, but also when the physical device (i. e. the motion sensor or the light switch on the wall) is triggered.

Once you have paired your first devices with FHEM, look at the event monitor to see when which events will be triggered.

A more comprehensive introduction to FHEM can be found in the document [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung-mit-FHEM] (German)

The basics of the programming language Perl, which are important for FHEM, can be read in the first chapters of a Perl book or in various free online tutorials.

Have fun and success with FHEM!

[[Kategorie:HOWTOS]]

----
----
This is the english version of [[Erste Schritte in FHEM]]
* Last edit German article: {{REVISIONDAY2: Erste Schritte in FHEM}}.{{REVISIONMONTH: Erste Schritte in FHEM}}.{{REVISIONYEAR: Erste Schritte in FHEM}}
* Last edit English article: {{REVISIONDAY2: First steps in FHEM}}.{{REVISIONMONTH: First steps in FHEM}}.{{REVISIONYEAR: First steps in FHEM}}
* '''Newer''' Version is: '''{{#ifexpr: {{REVISIONTIMESTAMP: Erste Schritte in FHEM}} > {{REVISIONTIMESTAMP: First steps in FHEM}}| dt. Version|engl. Version}}'''
----
----

Diskussion:Erste Schritte in FHEM

2024-12-05T07:14:12Z

Afo-solar: /* Attribut "disable" */

== Die Sache mit dem doppelten Semikolon ==

Gerade für den Anfänger an den sich dieses Dokument richtet, wäre es sehr wichtig zu verstehen, warum das Semikolon verdoppelt werden muss und was damit geschieht (''es wird nur einfach in DEF gespeichert''). Das wird hier nur anhand des daraus resultierenden Symptoms erklärt: "Sofort ausführen oder später". Aber das warum wäre m.E. gerade hier für das Verständnis beim Einstieg wichtig. Ansonsten ist es auch schwer nachzuvollziehen, warum man den gleichen Befehl den <code>notify</code> ausführen soll auf der Kommandozeile mit verdoppeltem Semikolon und beim editieren des Internals DEF dann wieder ohne Verdoppelung schreiben muss. Drei Überlegungen dazu:
# Könnte man das Beispiel mit der Verdoppelung noch um das Editieren des Internals DEF erweitern und dabei genau das erläutern. Ohne diese Erkenntnis ist die Tücke dieses Konstrukts schwer verständlich und der Anfänger wundert sich warum seine Lampe auf den Status <code>on; define a1 at +00:01 set myLampe1,myLampe2 off</code> o.Ä. gesetzt wird.
# Gibt es überhaupt sinnvolle Fälle, in denen ein verdoppeltes Semikolon im DEF benötigt wird. Spätestens bei dem hier benötigten vierfach Semikolon sollte man wissen was damit wann geschieht.
# Gibt es sinnvolle Zustände die ein Semikolon enthalten? Wäre da eine Warnung möglich?
Viele Grüße --[[Benutzer:MGu|MGu]] ([[Benutzer Diskussion:MGu|Diskussion]]) 18:10, 17. Apr. 2016 (CEST)

== Falsche und indirekte negative Darstellung von notify/at im Vergleich zu DOIF ==

Hallo!

Die bewertende Aussage "Bei der Kombination von Ereignis (Bewegungsmelder meldet eine Bewegung) und Zeitangaben werden die stärken des DOIF deutlich. Es ist nur eine Definition (Gerät) notwendig. Wollte man dies durch die Verwendung von at und notify lösen, wären mehrere Definitionen notwendig oder ausreichende Perl-Kenntnisse." insbesondere im Zusammenhang mit dem Beispiel halte ich für falsch und bringt Einsteiger auf eine vollkommen falsche Spur/Sichtweise.

Die nur zeitweise Ausführung eines notify bzw. at erreicht man durch Setzen des Attributes <code>disabledForIntervals</code>. Damit muss man für die Umsetzung des Beispiels beim notify nur das passende Zeitintervall im genannten Attribut setzen. Es sind keine weiteren Definitionen notwendig.

Wenn der DOIF-Abschnitt erhalten bleiben soll und meine Aussage richtig ist, dann bitte ich um kurzfristige Entfernung der Wertung und auch Darstellung der Lösung des erweiterten Beispiels mit einem notify und dem Attribut disabledForIntervals. Das Wiki sollte nach Möglichkeit eine neutrale Sichtweise vermitteln, wenn es nicht eindeutige Vor- oder Nachteile gibt, die ich hier nicht erkenne.

Da es sich um einen wichtigen Artikel handelt, werde ich spätestens morgen selbst Änderungen vornehmen, um nicht Einsteigern falsche Sichtweisen zu vermitteln.

Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 09:43, 12. Feb. 2017 (CET)
<hr />
:Bin auch für "rückgängig machen", insbesondere auch, da diese Seite auf dem Einsteigerdokument von Uli Maass basiert und nur mit seinem Einverständnis ins Wiki übernommen wurde. Darüber hinaus ist die DOIF-Ergänzung sicherlich als redaktionelle Erweiterung anzusehen und allein aus diesem Gesichtspunkt schon mit Uli abzustimmen. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:20, 13. Feb. 2017 (CET)
<hr>
::Jep, war auch mein erster Gedanke --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 09:27, 13. Feb. 2017 (CET)
<hr>
:::Habe die Änderungen komplett zurückgesetzt.
:::Begründung:
:::* die vergleichenden Aussagen sind falsch
:::* ein Einverständnis der redaktionellen Änderung liegt afaik nicht vor und die Änderung wurde hier nicht vorab diskutiert. (den Hinweis darauf im Vorspann des Artikels hatte ich zuvor übersehen)
:::Wiedereinbau ist nach Abstimmung mit Uli und mit korrekter Darstellung nach Review grundsätzlich möglich. Dazu Änderungsvorschläge hier auf der Diskussionsseite einstellen.
:::--[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 09:48, 13. Feb. 2017 (CET)
Ist der Abstimmungsvorbehalt nicht unzulässig? Oder gilt der Hinweis über dem Speichern-Button nicht für Alle Wiki-Benutzer "Falls du nicht möchtest, dass deine Arbeit hier von anderen verändert und verbreitet wird, dann klicke nicht auf „Seite speichern“."

Die vergleichenden Passagen werde ich ändern.

--[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 12:10, 13. Feb. 2017 (CET)
<hr>
:Hmm, diese Seite ist einfach ein Sonderfall. Uli Maas hat da ursprünglich ein PDF-Dokument erstellt, das lange als Einstiegslektüre zu FHEM gehandelt wurde. Ich habe nur damals nach Rücksprache mit ihm die Erlaubnis bekommen, das PDF ins Wiki zu übernehmen. Die "Rechte" liegen aber sozusagen immer noch bei Uli. Deswegen habe ich das extra in der Einleitung erwähnt. Sowie auch diesen Punkt: "Redaktionelle Änderungen und Erweiterungen aber bitte mit dem Autor (z.B. auf der zugehörigen Diskussionsseite) abstimmen."
:Wie gesagt, ein Sonderfall. Bitte nicht persönlich nehmen.
:--[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 12:52, 13. Feb. 2017 (CET)
<hr>
:
:Hallo!
:Abstimmungsvorbehalt liest sich hart :-) . Es ist eine Bitte, die Du wahrscheinlich übersehen hast, und die in diesem Fall (Artikel) ihre Begründung hat. Das ist ein wichtiger Grundlagenartikel der überall verlinkt wird und darum richtig und objektiv sein soll. Der Inhalt wurde zuvor von mehreren Personen reviewed. Änderungen sollten daher vorher abgesprochen und besprochen werden, damit sie auch richtig sind.
:Hätte ich den Artikel nicht auf der oberen Beobachtungsprioriät, wäre vielleicht falsches Wissen verbreitet worden und das ist für niemanden sinnvoll. Genau darum habe ich auch die schnelle Reaktion angekündigt und umgesetzt.
:Das Problem der Änderung durch jedermann ist auch ein Aspekt, warum das Einsteiger-PDF nicht im Wiki steht.
:Ich persönlich denke, dass man gewisse Bitten respektieren sollte. Genauso habe ich damals Damians Bitte respektiert, dass im Wiki die Anwendungsbeispiele zu [[DOIF]] entfernt werden und das umgesetzt. Er stand DOIF-Artikeln im Wiki insgesamt kritisch gegenüber. Deine Artikel zu DOIF wurden auch intern beratschlagt, ob sie im Sinne von Damian "zulässig" sind. Angesichts der sehr guten Qualität und auch Eurer engen Zusammenarbeit bei der Fortentwicklung von DOIF haben wir das als gegeben hingenommen.
:Insgesamt setzen wir im Wiki auf einen großzügiges Rechtesystem ohne Review vor Freigabe. Zudem darf jeder fast jede Seite ändern und anpassen. Bei Besonderheiten -wie hier- werden bisher entsprechende Bitten/Hinweise ausgesprochen, die man einhalten sollte.
:Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:49, 13. Feb. 2017 (CET)

Hallo,
ich bin gerne bereit hier einen Entwurf zum Review einzustellen, damit die Qualität des Artikels gewährleistet bleibt.
DOIF gehört als grundlegendes Automatisierungselement in ein Einstiegsdokument, da stimmst Du mir sicherlich zu.

Wenn Abweichungen zu den Wiki-Lizenzbedingungen mit einzelnen Autoren von euch vereinbart werden, solltet Ihr nicht deren Klärung, Abstimmung u. Einhaltung auf die Benutzer abwälzen, sondern nach dem Verursacherprinzip selbst durchführen. Zumal dem Benutzer nicht ohne Weiteres bekannt ist, unter welchem Avatar er den Autor findet.

Diese Forderung: "und auch Darstellung der Lösung des erweiterten Beispiels mit einem notify und dem Attribut disabledForIntervals." halte ich für pure Willkür, denn das gilt ja nur für mich, solange die anderen Beispiele nicht mit DOIF-Beispielen ergänzt werden. Sie ist sicherlich ähnlich entstanden, wie meine vergleichenden Textpassagen.

Den Absimmungsvorbehalt habe ich so verstanden, als Vorbehalt und ich habe ihn nicht über sehen, sondern ignoriert. Aber nicht ohne auf die Seite von Uli zu schauen, wo Du seit 16:26, 2. Okt. 2015 auf eine Antwort wartest.

'''Hier mein Vorschlag zum Review:'''

== Zeit- und Eventsteuerung, DOIF vereint at und notify ==
Aufgabenstellung: Ein Treppenhauslicht soll durch einen Bewegungsmelder eingeschaltet werden, aber nur zwischen 18 Uhr und 8 Uhr.

Bei der Kombination von [[Event|Ereignis]] (Bewegungsmelder meldet eine Bewegung) und Zeitangaben werden die Stärken des [[DOIF]] deutlich.

Zeitangaben erfolgen im [[DOIF]] in eckigen Klammern <code>[HH:MM]</code> für einen Zeitpunkt und <code>[HH:MM-HH:MM]</code> für eine Zeitspanne.

Hier ist vorausgesetzt, dass der Bewegungsmelder als Gerät mit dem Namen ''BM'' definiert wurde und er ein [[Readings|Reading]] mit dem Namen ''motion'' besitzt. Das [[Readings|Reading]] ''motion'' nimmt bei erkannter Bewegung den Wert ''on'' an und nach Verschwinden der Bewegung den Wert ''off''.
Auf die Statusänderung des Bewegungsmelders wird auch wieder über Angaben in eckigen Klammern <code>[gerätename:readingname]</code> zugegriffen.

Bei erkannter Bewegung soll geschaltet werden, also wenn der Status des BM auf ''on'' wechselt. Dies wird geprüft durch einen vergleichenden [https://de.wikipedia.org/wiki/Operator_(Mathematik) Operator] ''eq'' (equal). Die Zeitangaben und der Ereignisvergleich werden durch den logischen [https://de.wikipedia.org/wiki/Operator_(Mathematik) Operator] ''and'' verknüpft. Der set-Befehl wird ausgeführt, wenn die ganze Bedingung logisch wahr wird, das ist nur der Fall, wenn zwischen 18 Uhr und 8 Uhr eine Bewegung erkannt wird.

Die Definition des [[DOIF]] ist einfach:
<pre>define treppenhaus_di DOIF ([18:00-08:00] and [BM:motion] eq "on") (set th_Licht on-for-timer 60)</pre>
Es sind natürlich auch flexible Zeitangaben möglich, die sich auf den Sonnenauf u. -untergang beziehen.
<pre>define treppenhaus_di DOIF ([{sunset}-{sunrise}] and [BM:motion] eq "on") (set th_Licht on-for-timer 60)</pre>
Es können auch Zeiten angegeben werden, die in [[Readings]] des DOIF-Gerätes selbst stehen und über das WEB-Frontend verändert werden können.
<pre>define treppenhaus_di DOIF ([[$SELF:Beginn]-[$SELF:Ende]] and [BM:motion] eq "on") (set th_Licht on-for-timer [$SELF:Dauer])</pre>
[[Datei:ErsteSchritte DOIF.png]]

Weitere Ausführungen zum DOIF würden den Rahmen der ''ersten Schritte'' sprengen.
Wenn das Interesse an [[DOIF]] geweckt wurde, gibt es im [[DOIF/Labor_-_ausführbare,_praxisnahe_Beispiele_als_Problemlösung_zum_Experimentieren|DOIF Labor]] ausführbare Beispiele zum Importieren über [[Import_von_Code_Snippets|Raw definition]].

'''und die Ergänzung in: ''Sie haben nun kennengelernt:'' '''
* [[DOIF]]: Zusammenfassen von Ereignissteuerung ([[notify]]) und Zeitsteuerung ([[at]])

--[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 16:39, 13. Feb. 2017 (CET)

Ich habe eine Selbstrevision durchgeführt und den obigen Text überarbeitet.

--[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 18:30, 13. Feb. 2017 (CET)
<hr>
:Hallo allerseits,
:vielen Dank für die rege Diskussion zu diesem Artikel.
:In der Tat wär's mir wie geschrieben lieb, wenn redaktionelle Änderungen vor dem Einfügen mit mir abgesprochen würden.
:Bezgl. DOIF: ich kenne das Modul aus Posts und Diskussionen im Forum, nutze es aber selbst nicht und konnte/kann deshalb auch nix dazu schreiben. Insofern vielen Dank für die Zulieferung eines neuen Abschnitts.
:Da diese Anleitung sich speziell an den Einsteiger wendet, der vielleicht das erste mal nen Blick auf FHEM wirft, hab ich mit dem Einbinden des DOIF-Beispiels 2 Sorten Bauchschmerzen:
:1. es zeigt dem Neuling gleich beim allerersten Kontakt mit FHEM mehrere Alternativen für denselben Sachverhalt auf, das hallte ich für verwirrend.
:2. DOIF verwendet eine proprietäre Syntax in regexp - auch diese hat zumindest in der Anfangszeit das Potential, den Neuling zu verwirren.
:Mein Ansatz ist "Einfachheit durch weglassen" - das würde möchte ich auch auf diese Diskussion und mithin DOIF anwenden.
:Vorschlag: aus diesem Artikel rauslassen, aber in die nächste Version des Einsteiger-pdf aufnehmen - das ist ja wesentlich umfangreicher und versucht, möglichst viele hilfreiche Module vorzustellen und z.T. auch zu erklären - dort wäre so ein DOIF-Artikel m.E. wesentlich besser aufgehoben.
:Wenn ich endlich mal zur besagten nächsten Version komme, melde ich mich wieder mit der Bitte um input.
: Gruß und schönen Tag allerseits, Uli
:--[[Benutzer:Uli|Uli]] ([[Benutzer Diskussion:Uli|Diskussion]]) 09:12, 19. Feb. 2017 (CET)

<hr>
::Hallo Uli,
::ich habe die Bedenken hinsichtlich einer Ergänzung des Einsteigerartikels in meiner Naivität unterschätzt.
::Gegen die Abstimmung einer Ergänzung habe ich selbstverständlich nichts einzuwenden.
::Ich stehe voll hinter Deinem Ansatz "Einfachheit durch weglassen". Deshalb schlage ich vor, die Beispiele, die at und notify verwenden durch DOIF zu ersetzen, dann wird dem Einsteiger nur ein Modul zugemutet. Das ist möglich, weil durch DOIF die Angabe generischer Auslöser vereinfacht und harmonisiert wurde. DOIF funktioniert ohne Kenntnis "regulärer Ausdrücke".
::* Angabe eines Auslösers: <code>[<name>:<reading>] vs. <name>:<reading>.*</code>, eine einfache Readingsangabe reicht im DOIF
::* Angabe eines Zeitpunktes: <code>[HH:MM:SS] vs. *HH:MM:SS</code>,
::* und Angabe einer Zeitspanne, die einen Neustart überlebt: <code>[HH:MM:SS-HH:MM:SS] vs. *HH:MM:SS ...;;define at *HH:MM:SS ...</code>

::Diese wegweisende, von Dir als properitär bezeichnete Syntax, hat den Set-Befehl beeinflusst, bekannt als ''set magic'' <code>set <name> [<gerät>:<reading>]</code>.

::Wenn Du die Regexp-Syntax im DOIF als properitär bezeichnest, dann trifft das vielmehr auch auf die Syntax von at und notify zu, beim notify werden z.B. intern die Begrenzungszeichen ^ und $ gesetzt, ohne es in der Befehlereferenz zu erwähnen.
::Beispiel
::Ausgehend von den Events
<pre>
2017-02-21 19:25:09 dummy du3 B: off
2017-02-21 19:25:10 dummy du3 B: on
</pre>
::würde ich eine exakte Regexp so formulieren <code>^du3$:^B: (on|off)$</code>. Das funktioniert im notify nicht, im DOIF schon, also nur mal zum Thema "properitäre Syntax".

::Hier mein Gegenvorschlag: DOIF statt at und notify in die "ersten Schritte" aufnehmen.

::Dieser Vorschlag folgt Deinem Ansatz "Einfachheit durch weglassen" zielführend, daher bitte ich Dich diesen Vorschlag anzunehmen.

::DOIF ins Einsteiger-pdf aufzunehmen ist eine gute Idee, aber das kann ja noch dauern, wie Du selbst andeutest.

::LG Trelle

::--[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 20:22, 21. Feb. 2017 (CET)

Hallo an alle Beteiligten der Disskussion Erste Schritte,

die Antwortzeiten sind hier ja recht lang, da hatte ich Gelegenheit meinen Vorschlag für die Erweiterung der "Ersten Schritte" noch einmal gründlich zu überarbeiten. Es sollte jetzt keine Formulierungen mehr geben, die den Verdacht aufkeimen lassen könnten, dass at und notify nicht gleichberechtigte Partner-Module zu DOIF sein könnten. Damit sind dann auch [[DOIF]], die Befehlsreferenz und dieser Vorschlag harmonisiert.

'''Hier nun der überarbeitete Vorschlag:'''

== Zeit- und Ereignissteuerung mit DOIF ==
'''[[DOIF]]''' (ausgeprochen: du if, übersetzt: tue wenn) ist ein universelles Modul, welches [[Event|ereignis-]] und zeitgesteuert in Abhängigkeit definierter Bedingungen Anweisungen ausführt.

In einer Hausautomatisation geht es immer wieder um die Ausführung von Befehlen abhängig von einem [[Ereignis]]. Oft reicht aber eine einfache Abfrage der Art: "wenn [[Ereignis]] eintritt, dann Befehl ausführen" nicht aus. Ebenso häufig möchte man eine Aktion nicht nur von einem einzelnen [[Ereignis]] abhängig ausführen, sondern abhängig von mehreren Bedingungen, z. B. "schalte Außenlicht ein, wenn es dunkel wird, aber nicht vor 18:00 Uhr" oder "schalte die Warmwasserzirkulation ein, wenn die Rücklauftemperatur unter 38 Grad fällt und jemand zuhause ist". In solchen Fällen muss man mehrere Bedingung logisch miteinander verknüpfen. Ebenso muss sowohl auf Ereignisse wie auch auf Zeittrigger gleichermaßen reagiert werden.

An dieser Stelle setzt das Modul [[DOIF]] an. Es stellt eine eigene Benutzer-Schnittstelle zur Verfügung ohne Programmierkenntnisse in [https://de.wikipedia.org/wiki/Perl_(Programmiersprache) Perl] unmittelbar vorauszusetzen. Mit diesem Modul ist es möglich, sowohl [[Ereignis]]- als auch Zeitsteuerung mit Hilfe logischer Abfragen miteinander zu kombinieren. Damit können komplexere Problemstellungen innerhalb eines [[DOIF]]-Moduls gelöst werden, ohne Perlcode in Kombination mit anderen Modulen programmieren zu müssen.

Das [[DOIF]]-Modul bedient sich selbst des Perlinterpreters, damit sind beliebige logische Abfragen möglich. Logische Abfragen werden in DOIF/DOELSEIF-Bedingungen vornehmlich mit Hilfe von and/or-[https://wiki.selfhtml.org/wiki/Perl/Operatoren Operatoren] erstellt. Diese werden mit Angaben von Stati, [[Readings]], [[Internals]], [[Event|Events]] oder Zeiten kombiniert. Sie werden grundsätzlich in eckigen Klammern angegeben und führen zur Triggerung des Moduls und damit zur Auswertung der dazugehörigen Bedingung. Zusätzlich können in einer Bedingung Perl-Funktionen angegeben werden, die in [[FHEM]] definiert sind. Wenn eine Bedingung wahr wird, so werden die dazugehörigen Befehle ausgeführt.

Die vollständige Dokumentation mit zahlreichen Beispielen ist in der [https://fhem.de/commandref_DE.html deutschsprachigen Befehlsreferenz zum DOIF] zu finden.

Zusätzliche, ausführbare Beispiele zum [[Import von Code Snippets|Import]] in [[FHEM]], gibt es im [[DOIF/Labor - ausführbare, praxisnahe Beispiele als Problemlösung zum Experimentieren|DOIF Labor]]
=== Ereignissteuerung ===
{{Randnotiz|RNText=Hinweis: Verwendung von
* <code>[<Gerätename>:"<Ereignis>"]</code> zur Abfrage eines Ereignisses von einem Gerät
* '''DOELSE''' das Schlüsselwort leitet einen Befehlszweig ohne explizite Bedingung ein. Dieser Zweig wird ausgeführt, wenn keine geprüfte Bedingung wahr ist.
* '''devStateIcon''' zum direkten Ausführen eines Befehls im [[DOIF]] und zur Anzeige von Icons
}}
Aufgabenstellung: Eine Fernbedienung soll einen Fernseher einschalten, der über eine Funkstekdose angeschlossen ist.

Das Gerät '''Fernbedienung''' wird durch den Dummy '''remotecontrol''' dargestellt. In der Realität könnte es die Definition eines Empfängers für eine Infrarot-Fernbedienung sein.

Das Gerät '''Funksteckdose TV''' wird durch den Dummy '''tv''' dargestellt. In der Realität könnte es die Definition einer Intertechno-Funkstekdose aus dem Baumarkt sein.

Die Signale von '''remotecontrol''' werden über das DOIF '''di_rc_tv''' alias '''Steuerlogik''' in einen Befehl für die Funksteckdose '''tv''' umgesetzt.

Das Signal ist als [[Ereignis]] im [[Event monitor|Event-Monitor]] sichtbar <code>2017-02-28 09:07:03 dummy tv on</code>

Das [[DOIF]] reagiert durch die Angabe von <code>[remotecontrol:"on"]</code> in der Schaltbedingung. Weil '''on''' als Wert in dem Ereignis enthalten ist, wird die Bedingung wahr. Das bewirkt das Ausführen des Befehls <code>set tv on</code>. Danach nimmt das [[DOIF]] den Status '''cmd_1''' an.

Falls '''off''' im Ereignis enthalten ist wird die Bedingung nicht wahr, daher wird der Befehl <code>set tv off</code> des DOELSE-Zweiges des [[DOIF]] ausgeführt und [[DOIF]] nimmt den Status '''cmd_2''' an.

Definition:
<pre>define di_rc_tv DOIF ([remotecontol:"on"]) (set tv on) DOELSE (set tv off)</pre>

Über das [[Attribute|Attribut]] '''devStateIcon''' können die Befehle des [[DOIF]] direkt ausgeführt werden.
<pre>attr di_rc_tv devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1</pre>

Das erste Tripel <code>cmd_1:general_an:cmd_2</code> hat die Bedeutung ''aktueller Status''''':'''''Icon-Name''''':'''''Status nach Betätigung des Icons''. Also, wenn der Status '''cmd_2''' ist, dann zeige das Icon '''general_an''' und wenn das Icon betätigt wird, dann führe den Befehl aus, der zu '''cmd_1''' gehört.

Das zweite Tripel hat die gleiche Funktion, jedoch wird in diesem Fall das Icon '''general_aus''' angezeigt, wenn der Status des [[DOIF]] '''cmd_1''' ist oder '''initialized'''.

Die nachstehende, komplette Definition für die Gruppe A) kann über '''[[Import von Code Snippets|Raw definition]]''' in [[FHEM]] importiert werden.
<pre>
defmod di_rc_tv DOIF ([remotecontrol:"on"]) (set tv on) DOELSE (set tv off)
attr di_rc_tv alias Steuerlogik
attr di_rc_tv devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1
attr di_rc_tv group A) Fernbedienung (Ereignissteuerung)
attr di_rc_tv icon helper_doif
attr di_rc_tv room Schulungsraum

defmod remotecontrol dummy
attr remotecontrol alias Fernbedienung
attr remotecontrol devStateIcon .*:noIcon
attr remotecontrol group A) Fernbedienung (Ereignissteuerung)
attr remotecontrol icon it_remote
attr remotecontrol room Schulungsraum
attr remotecontrol webCmd on:off

defmod tv dummy
attr tv alias Funksteckdose TV
attr tv devStateIcon on:it_television@red off:it_television@blue
attr tv group A) Fernbedienung (Ereignissteuerung)
attr tv icon it_television
attr tv room Schulungsraum
save
</pre>
=== Zeitsteuerung ===
{{Randnotiz|RNText=Hinweis: Verwendung von
* <code><nowiki>[<Zeitpunkt>|<Wochentagangabe>]</nowiki></code> zur Angabe eines Zeitpunktes mit Wochentagbeschränkung (8 ≙ werktags, 7 ≙ Wochenende).
* '''DOELSEIF''' das Schlüsselwort leitet einen Bedingungszweig ein und muss eine Bedingung enthalten. Dieser Zweig wird ausgeführt, wenn eine Bedingung geprüft wird und sie wahr ist.
* '''devStateIcon''' zum direkten Ausführen eines Befehls im [[DOIF]] und zur Anzeige von Icons
}}
Aufgabenstellung: Ein Radio soll werktags und am Wochenende zu unterschiedlichen Zeiten ein- u. ausgeschaltet werden.

Das Gerät '''Funksteckdose Radio''' wird durch den Dummy '''radio''' dargestellt. In der Realität könnte es die Definition einer Intertechno-Funkstekdose aus dem Baumarkt sein.

Wenn die Uhrzeit mit einem Schaltzeitpunkt übereinstimmt, wird die Zeitpunktangabe wahr. Wird dann auch die gesamte Bedingung wahr, dann wird der zu diesem Bedingungszweig gehörende Befehl ausgeführt. Das [[DOIF]] '''di_clock_radio''' alias '''Zeitschaltuhr''' setzt dann einen Befehl zum Schalten der Funksteckdose '''radio''' ab.

Das Zeitereignis ist im [[Event monitor|Event-Monitor]] nicht sichtbar.

Die Zeitpunkte eines Bedingungszweiges sind '''or'''(oder) verknüpft. Im ersten Bedingungszweig steht die Einschaltbedingung, im Zweiten (DOELSEIF) die Auschaltbedingung.

Definition:
<pre>define di_clock_radio DOIF ([06:30|8] or [08:30|7]) (set radio on) DOELSEIF ([08:00|8] or [09:30|7]) (set radio off)</pre>

Über das [[Attribute|Attribut]] '''devStateIcon''' können die Befehle des [[DOIF]] über das WEB-Frontend unabhängig von den Schaltzeitpunkten ausgeführt werden.
<pre>attr ddi_clock_radio devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1</pre>

Die nachstehende, komplette Definition für die Gruppe B) kann über '''[[Import von Code Snippets|Raw definition]]''' in [[FHEM]] importiert werden.
<pre>
defmod di_clock_radio DOIF ([06:30|8] or [08:30|7]) (set radio on) DOELSEIF ([08:00|8] or [09:30|7]) (set radio off)
attr di_clock_radio alias Zeitschaltuhr
attr di_clock_radio devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1
attr di_clock_radio group B) Zeitschaltuhr (Zeitsteuerung)
attr di_clock_radio icon helper_doif
attr di_clock_radio room Schulungsraum

defmod radio dummy
attr radio alias Funksteckdose Radio
attr radio devStateIcon on:it_radio@red off:it_radio@blue
attr radio group B) Zeitschaltuhr (Zeitsteuerung)
attr radio icon it_radio
attr radio room Schulungsraum
save
</pre>

=== Kombinierte Ereignis- und Zeitsteuerung ===
{{Randnotiz|RNText=Hinweis: Verwendung von
* <code><nowiki>[<Beginzeitpunkt>-<Endzeitpunkt>]</nowiki></code> zur Angabe einer Zeitspanne.
* <code>[<Gerätename>:<Reading-Name>]</code> zur Abfrage eines Reading-Inhaltes.
* <code> < </code>, eines numerischen Vergleichsoperators und Vergleich mit einer Konstanten (40).
* '''DOELSE''' das Schlüsselwort leitet einen Befehlszweig ohne explizite Bedingung ein. Dieser Zweig wird ausgeführt, wenn keine geprüfte Bedingung wahr ist.
* '''devStateIcon''' zum direkten Ausführen eines Befehls im [[DOIF]] und zur Anzeige von Icons
* '''readingList''', '''setList''' und '''webCmd''' zur Erzeugung eines Eingabeelementes im Frontend
* '''stateFormat''' um einen benutzerdefinierten Status zu erzeugen.
}}
Aufgabenstellung: Eine Lampe soll in einer Zeispanne eingeschaltet werden, wenn die Helligkeit einen bestimmten Wert unterschreitet.

Das Gerät '''Lampe''' wird durch den Dummy '''lamp''' dargestellt. In der Realität könnte es die Definition einer funkgesteuerten Lampenfassung sein.

Das Gerät '''Helligkeitssensor''' wird durch den Dummy '''sensor''' dargestellt. In der Realität könnte es die Definition eines Homematic Funk-Lichtsensor sein oder ein selbstgebauter Helligkeitssensor mit TSL2561-Chip.

Wenn die aktuelle Uhrzeit in der angegebenen Zeitspanne liegt, ist die Zeitspanne wahr. Wenn dann auch die Helligkeit unter 40 sinkt, wird die gesamte Bedingung wahr, weil Zeitspanne und Hellikeitsvergleich '''and'''(und) verknupft sind. Der zu diesem Bedingungszweig gehörende Befehl wird dann ausgeführt. Das [[DOIF]] '''di_lamp''' alias '''Lampenlogik''' setzt dann einen Befehl zum Schalten der Lampe '''lamp''' ab.
Der DOELSE-Zweig wird ausgeführt, wenn die Bedingung im ersten Zweig unwahr wird.

Definition:
<pre>define di_lamp DOIF ([06:00-19:00] and [sensor:brightness] < 40) (set lamp on) DOELSE (set lamp off)</pre>

Über das [[Attribute|Attribut]] '''devStateIcon''' können die Befehle des [[DOIF]] über das WEB-Frontend unabhängig von den Schaltzeitpunkten ausgeführt werden.
<pre>attr di_lamp devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1</pre>

Das [[Attribute|Attribut]] '''setList''' zusammen mit '''readingList''' und '''webCmd''' realisiert im Gerät '''sensor''' für das Reading '''brightness''' einen Schieberegler, mit dem eine Helligkeit zwischen 0 und 100 in in Schritten von 1 simuliert werden kann und der im Frontend angezeigt wird.
<pre>
attr sensor readingList brightness
attr sensor setList brightness:slider,0,1,100
attr sensor webCmd brightness
</pre>

Mit dem [[Attribute|Attribut]] '''stateFormat''' wird im Gerät '''sensor''' das Reading '''brightness''' in den Status geschrieben. Damit wird der Helligkeitswert auch im Frontend sichtbar.
<pre>
attr sensor stateFormat brightness</pre>

Die nachstehende, komplette Definition für die Gruppe C) kann über '''[[Import von Code Snippets|Raw definition]]''' in [[FHEM]] importiert werden.
<pre>
defmod di_lamp DOIF ([06:00-19:00] and [sensor:brightness] < 40) (set lamp on) DOELSE (set lamp off)
attr di_lamp alias Lampenlogik
attr di_lamp devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1
attr di_lamp group C) Kombinierte Ereignis- und Zeitsteuerung
attr di_lamp icon helper_doif
attr di_lamp room Schulungsraum

defmod lamp dummy
attr lamp alias Lampe
attr lamp group C) Kombinierte Ereignis- und Zeitsteuerung
attr lamp icon light_light
attr lamp room Schulungsraum

defmod sensor dummy
attr sensor alias Helligkeitssensor
attr sensor group C) Kombinierte Ereignis- und Zeitsteuerung
attr sensor icon message_light_intensity
attr sensor readingList brightness
attr sensor room Schulungsraum
attr sensor setList brightness:slider,0,1,100
attr sensor stateFormat brightness
attr sensor webCmd brightness
save
</pre>

=== Ansicht der Gruppen A) bis C) im Frontend ===

[[Datei:erste_schritte_DOIF.png|670px]]

'''und die Ergänzung in: Sie haben nun kennengelernt:'''

* DOIF: Ereignis-und Zeitsteuerung

LG --[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 19:16, 1. Mär. 2017 (CET)

<hr>
:Hi Trelle,
:die langen Antwortzeiten liegen im Wesentlichen daran, dass ich keine Mailbenachrichtigung kriege, wenn hier was geschrieben wird. (vielen Dank an Christian für den Hinweis)
:Mach doch aus der DOIF-Ausarbeitung eine separate Wiki-Seite. Am Ende der Erste-Schritte-Abschnitte zu notify und at können wir dann nen Hinweis einfügen à la: "Hinweis: Als Alternative zu den Befehlen <at|notify> gibt es auch das Modul DOIF, mit dem vor allem komplexere Bedingungen einfacher abzubilden sind."
: Gruß und schönen Tag, Uli
:--[[Benutzer:Uli|Uli]] ([[Benutzer Diskussion:Uli|Diskussion]]) 09:12, 19. Feb. 2017 (CET)

{{Anker|neue_Antwort}}
::Hallo Uli,

::Es geht nicht darum, dass im Wiki etwas über DOIF geschrieben wird, da gibt es schon eine Menge.

::Es geht darum, Einsteigern beim Erstkontakt über die "Ersten Schritte ..." eine ernstzunehmende Möglichkeit der Zeit- und Eventverarbeitung nicht vorzuenthalten, sondern Sie auf Augenhöhe anzubieten.

::Das Verschweigen dieser Möglichkeit lässt Einsteiger nicht Ihren besten Weg finden und kommt einer Bevormundung gleich.

::Die Disskussion um at, notify und DOIF lässt 3 Gruppierungen erkennen at/notify bzw. DOIF Puristen und die Mischer. Es gibt keinen Grund anzunehmen, dass diese Vorlieben nicht auch bei Einsteigern angelegt sind.

::Gerade als Marketing Verantwortlicher des Vereins solltest Du ein Interesse haben, allen Gruppen einen leichten Einstieg zu ermöglichen, auch mit Blick auf die sich ankündigende Verbreitungsoffensive (FHEM-Livesystem und Showcases, usw.)

::Du kennst DOIF, nicht hast Du erwähnt, dass sollte Dich nicht abhalten es dennoch ernstzunehmen und von eigenen Vorlieben unabhängig zu betrachten, um den Mehrwert für FHEM erkennen zu können.

::Zur Verkürzung der Antwortzeiten könnten wir die Disskussion auch ins Forum verlagern. Was hältst Du davon?

::LG --[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 12:27, 4. Mär. 2017 (CET)
{{Anker|neue_Antwort}}
:::Hallo Trelle,
:::offengestanden hab ich gar keine Lust auf diese Diskussion.
:::Offenbar haben wir hier unterschiedliche Ansichten. Ich respektiere Deine, respektiere Du bitte meine.
:::Einen Link auf eine DOIF-Seite können wir wie oben vorgeschlagen gerne einbauen, mehr Veränderung möchte ich an diesem Artikel nicht vornehmen.
:::Gruß, Uli
:::PS: Mit meiner Rolle im Verein hat das nix zu tun, es geht ja nicht um ein Vereinsthema.
:::--[[Benutzer:Uli|Uli]] ([[Benutzer Diskussion:Uli|Diskussion]]) 09:12, 19. Feb. 2017 (CET)

{{Anker|neue_Antwort1}}
::::Hallo Uli,

::::nachstehend 2 Vorschläge, wie ich einen Verweis auf die Zeit- und Eventsteuerung mit DOIF einbauen möchte.

::::Welchen Vorschlag bevorzugst Du?

::::LG --[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 18:55, 16. Mär. 2017 (CET)

Vorschlag 1

...
Da das ja doch recht sperrig ist, gibt es noch eine etwas einfachere Alternative:
define n_th_Schalter_on notify th_Schalter:on set th_Licht on;;sleep 60;;set th_Licht off

Manche Hardwaresysteme bieten auch den Befehl ''on-for-timer'', mit dem man alternativ schreiben kann
define n_th_Schalter_on notify th_Schalter:on set th_Licht on-for-timer 60

=== Zeit- und Ereignissteuerung mit DOIF ===
Seit erscheinen des ursprünglichen Artikels Anfang 2014, ist eine neue Möglichkeit der Zeit- und Ereignissteuerung eingeführt worden.

Siehe: [[DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erläuterungen#Erste_Schritte_mit_DOIF:_Zeit-_und_Ereignissteuerung|'''Erste Schritte mit DOIF: Zeit- und Ereignissteuerung''']]

Der Autor des usprünglichen Artikel hat freundlicherweise zugestimmt den Artikel mit einem Link zu ergänzen.
==Wie geht es weiter?==
...

Vorschlag 2
==Timer bei einem Event starten - notify und at==
{{Randnotiz|RNText='''Zeit- und Ereignissteuerung mit DOIF'''
Seit erscheinen des ursprünglichen Artikels Anfang 2014, ist eine neue Möglichkeit der Zeit- und Ereignissteuerung eingeführt worden.

Siehe: [[DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erläuterungen#Erste_Schritte_mit_DOIF:_Zeit-_und_Ereignissteuerung|'''Erste Schritte mit DOIF: Zeit- und Ereignissteuerung''']]

Der Autor des usprünglichen Artikels hat freundlicherweise zugestimmt den Artikel mit einem Link zu ergänzen.}}

Als letzte Übung wollen wir ein ''notify'' und ein ''at'' verbinden. Der Timer soll nun nicht starten, wenn Sie den Befehl in das Kommandofeld eingeben, sondern wenn ein Event eintritt.

Dazu basteln wir uns ein Treppenhaus: Legen Sie dafür die Dummy-Devices ''th_Schalter'' und ''th_Licht'' im Raum ''Treppenhaus'' an. Zum Anlegen des Raums ''Treppenhaus'' ordnen Sie dem ersten Device den Raum über das Kommandofeld zu, alle weiteren Attribute dann durch Klicken im Detail-Bildschirm:
define th_Schalter dummy
attr th_Schalter room Treppenhaus
attr th_Schalter webCmd on
define th_Licht dummy
attr th_Licht room Treppenhaus
...

<hr>
:Für mich sind beide Varianten ok. Wobei ich nicht sicher bin, ob eine Platzierung unter "Wie geht es weiter?" der Universalität von DOIF nicht gerechter würde. Unter "Timer bei einem Event starten..." wird die Bedeutung mMn ein wenig reduziert. Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:04, 29. Mär. 2017 (CEST)

== Änderungen am Artikel "Erste Schritte in FHEM" ==
Betrifft folgende Änderungen des Users Andies: https://wiki.fhem.de/w/index.php?title=Erste_Schritte_in_FHEM&type=revision&diff=21496&oldid=21488

Diskussion wurde nachträglich zur besseren Nachvollziehbarkeit von [[Benutzer_Diskussion:Andies]] hierin verlagert. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 10:41, 12. Mai 2017 (CEST)

[[Benutzer_Diskussion:Andies]] schlägt vor, diesen Abschnitt zu löschen. Die Sachen sind ja (in meinen Augen) umgesetzt und durch, momentan müllt das nur die Diskussionsseite zu. Was meint Ihr? --[[Benutzer:andies|Andreas]] 08:21, 03. März 2019 (CEST)
<hr />
:''Dagegen'' - Für weitere / andere Änderungen kann ja gern (wir üblich) ein neuer Abschnitt begonnen werden. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 16:46, 3. Mär. 2019 (CET)

<HR>

Hallo!

Zunächst danke für Deine Mitarbeit am Wiki und bei FHEM. Aber -wie so oft im Leben- gibt es nur Rückmeldungen bei "Problemen" ;-) :

Hast Du Deine Änderungen am Artikel [[Erste Schritte in FHEM]], so wie im Vorwort zum Artikel erbeten, mit dem Verfasser Uli abgestimmt?

Die Änderungen widersprechen deutlich der Intention und dem Konzept des Artikels. Der Artikel soll nur einen kurzen Einstieg in FHEM geben; quasi einen "Vorgeschmack" auf FHEM liefern und nicht das Einsteiger-Pdf ersetzen.

Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:51, 9. Mai 2017 (CEST)

Ja, habe ich abgestimmt. Ich hatte ihm vor einer Woche eine Mail geschrieben und er hat daraufhin OK gesagt, aber darum gebeten, es möglichst kurz zu halten. Kurze Nachfrage: Was genau ist der ''deutliche'' Widerspruch zur Intention?

--[[Benutzer:andies]] 14:09, 9. Mai 2017

<HR>
:Hallo andies!
:[[Erste_Schritte_in_FHEM#Grundbegriffe:_Device_und_Internal.2C_Attribut.2C_Reading]] geht meiner Meinung nach viel zu sehr in die Tiefe und ist gerade für einen groben Überblick nicht notwendig. Finde das persönlich eher verwirrend als hilfreich. Was interessiert mich bspw. beim ersten Kontakt mit FHEM, warum 98 vor einem Modul steht? Wofür muss man das für den schnellen Überblick wissen? Variablen, Zeichenketten, STATE, Readings, Internal, Attribut im "Vorwort" als Grundbegriffe schrecken mich ab. Das kommt doch im Artikelverlauf von selbst und muss man nicht schon im Vorhinein lesen. Der "device"-Erläuterung kann ich hingegen eine gewisse Notwendigkeit abgewinnen.
:Inhaltlich bin ich nicht im Detail eingestiegen, aber "Readings sollen während der Laufzeit vom Anwender" halte ich als Aussage für sehr gefährlich.
:Erlaube mir mal eine Gegenfrage: Hast Du beim Einstieg das Einsteiger-Pdf gelesen? Oder wie bist Du vorgegangen?
:Wenn Du die Änderungen mit Uli abgestimmt hast, ist das Ok und ich bin ruhig :-).
:Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 15:28, 9. Mai 2017 (CEST)

<HR>
::Danke für die konstruktive Antwort; dann lass uns diskutieren! Ich erzähle mal, wieso ich das geschrieben habe und dann schauen wir, was wir am Ende daraus machen. Das wird jetzt aber ein längerer Text (Wir können das auch im Forum diskutieren, wäre das besser? Wenn ja, dann nimm einfach den Link, den ich da angegeben habe: https://forum.fhem.de/index.php/topic,71397.0.html). Ich habe mit FHEM angefangen, weil ich ein ganz konkretes Problem hatte, dass ich mit anderen Servern nicht habe lösen können (Garage übers Internet schalten, Rolladen auch) und ich glaube, dass das typisch ist - jedenfalls war das der Eindruck, den ich von einem Treffen in Berlin hatte. Dann habe ich die Einsteiger-PDF gelesen und hatte "irgendwie" Ahnung, wie das geht. Dann habe ich meine Rolladen in Griff gehabt und eigentlich wäre dann alles gut gewesen. Wäre ich da stehen geblieben, hätte ich den Wiki-Eintrag ''nicht'' verändert.
:: Der nächste Schritt war dann, dass ich (wie wahrscheinlich einige hier) Blut geleckt hatte. Nun sollte also auch noch der Stromverbrauch erfasst werden etc. Und auf einmal fingen die Probleme an. Ich habe zum Beispiel aus dem Wiki-Eintrag nicht verstanden, was überhaupt ein Attribut ist. Ständig wollte ich mit ReadingsVal die Werte der Attribute auslesen und bekam auch mal den Anpfiff: "Lies mal die commandref". Wenn man aber noch nie mit Perl programmiert hat, kapiert man das auch nach dem zehnten Lesen nicht. Hinzu kommt, dass einige Dinge so erklärt sind, dass für einen Anfänger ein Verständnis nahezu unmöglich wird; einige Wiki-Einträge sind ja wirklich verwaist. Also habe ich überlegt: Warum kapiere ich das nicht? Dann wurde mir klar, weil zum einen recht viele kleine Schusselfehler in der Einleitung stehen (zum Beispiel "Reading 'STATE'", wo es doch ein Internal ist oder man das Reading 'state' meint etc pp - so etwas verwirrt einen Anfänger total!) und zum anderen weil mehrere Grundbegriffe nicht vernünftig erklärt sind (zum Beispiel: "Nur Readings können von Menschen gelesen werden" - Internals auch!). Hinzu kommt, dass in der Einleitung zwar steht, was man genau tun soll ("tipp mal attr XY room sowieso" ein und dann siehst du was), aber nicht erklärt wird, ''was'' man da eigentlich macht - nämlich ein Attribut setzen und einen Wert zuweisen. Deshalb habe ich mich dran gesetzt und überlegt, was '''für mich''' wichtig gewesen wäre.
:: Nun zur Debatte. Was für mich wichtig ist, kann für andere verwirrend sein. Sehe ich sofort ein. Also lass uns im Detail diskutieren, was am Text verändert wird (nochmal: eventuell im Forum?). Das mit der Zeichenkette verstehe ich, das mit den Definitionen der Grundbegriffe finde ich aber wesentlich. Wir sollten vielleicht so debattieren: Was wollen wir beim Anfänger erreichen? Welches Vorwissen müssen wir voraussetzen, was nicht? Ich gehe davon aus, dass der typische Anwender mit einem ganz konkreten Problem zu FHEM stößt und zuerst das gelöst haben will. Dass er wenige Programmierkenntnisse besitzt und auch bereit ist, gewisses Leid in Kauf zu nehmen. Wir können aber nicht voraussetzen (auch wenn das der eine oder andere meint), dass er die gesamte Einsteiger-PDF verstanden, die commandref gelesen und verstanden hat und außerdem mit RegEx problemlos umgehen kann. Wenn wir uns bei der Beschreibung der Person, die den Wiki-Eintrag liest, einig sind, sollte sich ein besserer Text ergeben. Das man dabei sinnvollerweise vermeidet, bereits in der Einleitung eine Debatte zum Sinn und Unsinn von DOIF zu haben, ist auch mir Anfänger klar.
<HR>
:::Zum Diskussionsort: Mir ist es letztlich gleich. Hier wird es vmtl. nur ruhiger und mit weniger Beteiligung als im Forum zu gehen.

:::Also bist Du zum Einstieg mit dem Artikel "Erste Schritte in FHEM" problemlos klargekommen; erst als es weiter in die Tiefe ging, kamen die weiteren Probleme!? Daraus schließe ich zunächst einmal frech, dass der Artikel seinen Zweck erfüllt hat: Ein "Appetitanreger" auf FHEM, der erste Erfolgserlebnisse und erstes Verständniss schafft. Mehr soll er meiner Meinung nach auch nicht. Der Einsteiger soll sich in kurzer Zeit einen Überblick verschaffen (Zeitbedarf max. 60 Minuten): Ist FHEM etwas für mich? Wie geht das grundlegend? Wenn man neugierig geworden ist, dann weiterlernen.

:::Tippfehler und Co. (state vs. STATE) sollten im Artikel natürlich behoben werden. Mit Deinen weiterführenden Erläuterungen insb. Grundbegriffe, die Du nach den ersten Erfolgserlebnissen vermisst hast, steigt der Zeitbedarf für die Durcharbeitung und auch die Komplexität des Artikels deutlich. Er verliert damit eben seine eigentliche Intention. Das, was unter Grundbegriffe steht braucht man zum Einstieg nicht und verwirrt. Er entwickelt sich mMn dadurch in Richtung universellen Einsteiger-PDF Ersatz. Weitergehende Informationen könnte man aus dem Artikel ja verlinken statt sie darin aufzunehmen; aber selbst dabei bin ich zweifelnd, da es schnell zum Verzetteln in Details führt.

:::Auch Deine Definition der Grundbegriffe ist, wie Du im Forum liest, nicht unumstritten. Und die Bedenken kommen nicht von irgendjemanden, sondern von einem der Kern-Developer. Einen Punkt hatte ich gestern auch schon herausgepickt (Readings), den ich persönlich für gefährlich oder eher sogar falsch halte. Zudem existieren schon Definitionen der Begriffe im Wiki, die man verlinken könnte. Warum sollten wir 2 Definitionen im Wiki pflegen? Das ist zu pflegeaufwendig. Das ist aber auch eine Macke von mir: [https://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=prev&oldid=21335] würde ich z.B. nicht so ausführlich machen, sondern auf [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden]] verlinken. Dadurch sind Fehler/Änderungen nur an einer Stelle zu berücksichtigen.

:::Wo steht eigentlich: "Nur Readings können von Menschen gelesen werden" ?

:::Was für Dich wichtig ist, liegt doch an Deinem Wissensstand. Zunächst hat der Einsteiger-Artikel gereicht. Dann ist man weiter und liest das Pdf. Und dann kommen Fragen und noch mehr Fragen. Damit bin ich wieder beim Ausgangspunkt, dass Deine Erläuterungen schon für Fortgeschrittenere sind und nicht in den genannten Artikel sollten ;-).

:::Was ich voraussetze? Nichts außer Lernbereitschaft. Dazu gehört auch, dass man sich zumindest mal Grundzüge von Perl anschaut. (Bin selbst kein Entwickler und werde keiner, sondern nur Anwender) Ohne Regex und Co. ist FHEM schwer "verdaulich". Das z.B. tritt mir mittlerweile zu sehr in den Hintergrund.

:::Mir persönlich wäre es am Liebsten den Einsteiger-Artikel in die Kurzform zurückzubringen und Deine Überlegungen möglichst redudanzfrei in weiterführende Artikel zu packen oder in Ulis Einsteiger-Pdf einzubringen, falls er Hilfe mag. Was ich nicht möchte ist: Dich entmutigen und von der Mitarbeit abbringen, das wird nämmlich schnell so aufgefasst. Und meine Meinung muss auch nicht die Richtige sein, wenn es die überhaut gibt.

:::Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 11:14, 10. Mai 2017 (CEST)

:::PS: (Langfristiges) Ziel ist bspw. [[FHEM_Installation_Windows]] und [[Erste Schritte in FHEM]] so zu gestalten, dass als Einsteiger ein Test von FHEM angefangen bei Installation bis zum Ende der ersten Experimente in ca. 90 Minuten möglich ist.

<HR>

::::Was ist davon zu halten, wenn wir den Grundbegriffe-Artikel zu einem Absatz mit ein, zwei Sätzen zusammenkürzen und den Inhalt auf weiterführende Seiten verschieben? Das wäre dann, in schlechtem Deutsch von der Idee her so: "Also wir legen jetzt mal los und wir brauchen dazu Attribute und Readings (was das ist, kannst du HIER nachlesen), aber erst einmal reicht <XYZ>"? Das können wir bei den anderen Abschnitten, bei denen Du Probleme hast, auch machen. Ich würde mir dann mal was überlegen und das hier vorstellen? Es wäre aber wegen der reparierten Schreibfehler vermutlich einfacher, wenn wir diesen Abschnitt _bearbeiten_ und _nicht_ zurückstellen, denn ich weiß nicht mehr, welche Fehler ich genau geändert habe.

<HR>
:::::Ich mache nichts einfach rückgängig, wir diskutieren doch: Ändere es einfach einmal so ab, wie Du es dann machen würdest. Im Übrigen bin ich nicht der Nabel der Welt, aber habe ein Meinung :-) . Am meisten stören mich die "Grundbegriffe". --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 16:08, 10. Mai 2017 (CEST)
<HR>

::::PS Aus dem Wiki: "Daten, welche von einem Gerät gelesen werden und in FHEM in einer für Menschen verständlichen Form zur Verfügung gestellt werden können, werden Readings genannt". Der Logiker schließt daraus, dass Internals für Menschen nicht verständlich sind (jedenfalls habe ich mich das wirklich gefragt: gilt etwa Readings = UTF-8, Internals = binär o.Ä?!)

<HR>
:::::Halte ich für eine erhebliche Überinterpretation der Aussage. Es wird doch nirgends eine Verbindung oder gar Vergleich zwischen Internals und Readings hergestellt und schon gar nicht, in welcher ihrer Merkmale/Eigenschaften aus Anwendersicht ein Gegensatz besteht. Eine klare und eindeutige Definition der Begriffe ist nicht so einfach und letztlich auch im Fluß. Zudem versuchst Du Begrifflichkeiten, die mMn eher aus Entwicklersicht entstanden sind, in ein Schema der Anwendersicht zu pressen. Ein bedeutendes Gegenbeispiel Deiner Definition finde ich beispielsweise auf die Schnelle noch bei Internals. Du schreibst: "Internals sollen vom Nutzer nicht direkt verändert werden". Das ist so vereinfacht in einem wesentlichen Punkt falsch. Das DEF in den Internals soll gerade von Einsteigern genutzt werden und nicht die manuelle Editierei in der fhem.cfg (siehe bspw. [[Konfiguration#Objektdetails]]). Die Nutzung des DEF wollen wir gerade den Einsteigern krampfhaft vermitteln; jetzt verbieten wir es aber bereits in der Definition im "Vorwort" des Einsteiger-Artikels. Das verwirrt sicherlich. Wenn Du das dann gerade ziehen willst, musst Du noch mehr erklären. Das führt zu mehr Verwirrung. Darum eben besser Definitionen weglassen. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 16:08, 10. Mai 2017 (CEST)
<HR>
::::::Ich habe jetzt erst einmal Änderungen vorgenommen, wie sie hier oben besprochen wurden. Genauer habe ich folgendes gemacht: Ich habe den separaten Abschnitt "Grundbegriffe" entfernt und Teile davon, die nicht technisch sind, in den fortlaufenden Text integriert. Das mit den Zeichenketten habe ich weggelassen. Ansonsten habe ich bei den ersten beiden Befehlen in FHEM etwas mehr Wert darauf gelegt, was man genau da eigentlich eingibt und welche Teile dieser Befehlszeile Syntax sind und wo man (mehr oder weniger) schreiben kann, was man will. --[[Benutzer:andies|Andreas]] ([[Benutzer Diskussion:andies|Diskussion]]) 18:51, 20. Mai 2017 (CEST)

== Attribut "disable" ==
Hallo alle,

zum Einstieg in FHEM habe ich den Text "Erste Schritte in FHEM" gelesen und fand, dass es Spass macht, FHEM so auszuprobieren und fand den Text und die Dummy-Experimente auch ziemlich gut. Ich hatte am Anfang Schwierigkeiten, die Attribute über die Detailansichten zu ändern, am nächsten Tag habe ich dann gemerkt, dass im Text immer steht, dass man auf den Button "attr" klicken soll. Das war also eigene Dummheit ...

Aber an einer Stelle, denke ich sollte der Text geändert werden. Nämlich dort, wo von n_mySwitch1_off das Attribut disable auf 1 gesetzt werden soll. Das geht beim ersten Mal gar nicht über die Detailansicht, da es dort anfangs nicht auftaucht. Daher habe ich den entsprechenden Text geändert auf: "Geben Sie dazu in der Kommandozeile attr n_mySwitch1_off disable 1 ein. Dadurch taucht in der Detailansicht des Notify im unteren Bereich das Attribut disable auf. Dieses kann man nun auf zwei Arten ändern, entweder über die Kommandozeile oder über die Detailansicht (dort den Wert 1 oder 0 auswählen, dann attr klicken)." Ich hoffe das ist ok. Ulrich Maas kann man zur Zeit - soweit ich das verstanden habe - nicht kontaktieren, deshalb habe ich den Änderungsvorschlag direkt in den Text geschrieben.

Grüße Felix
--[[Benutzer:Afo-solar|Afo-solar]] ([[Benutzer Diskussion:Afo-solar|Diskussion]]) 14:55, 22. Nov. 2024 (CET)
<hr>
:Alternativ kann das Attribut "disable" (wie alle anderen relevanten Attribute auch) aber auch in der Drop-Down Liste der Attribute ausgewählt werden; dann lässt sich auch ohne Eingabe eines Befehls der gewünschte Wert setzen. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 18:40, 22. Nov. 2024 (CET)
<hr>
:Hallo Peter, du hast mich überzeugt. Dass man das Attribut aus der Drop-Down-Liste auswählen kann, hatte ich übersehen. Den Teil des "Erste-Schritte"-Texts habe ich nochmals geändert und die Drop-Down-Liste explizit erwähnt.
Grüße Felix
--[[Benutzer:Afo-solar|Afo-solar]] ([[Benutzer Diskussion:Afo-solar|Diskussion]]) 08:14, 05. Dez. 2024 (CET)

Erste Schritte in FHEM

2024-12-05T07:09:26Z

Afo-solar: Die vorigen Änderungen habe ich zum Teil rückgängig gemacht, jedoch jetzt explizit die Drop-Down-Liste neben "attr" erwähnt.

Für alle, die das erste mal mit FHEM arbeiten, hier ein kleiner Kurs zum Einstieg.
Dieser ist so aufgebaut, dass man noch keine Hardware benötigt und nach dem Installieren der FHEM-Software sofort loslegen kann.

Diese Anleitung wurde ursprünglich von Ulrich Maass publiziert, der die Genehmigung erteilt hat, sie auch im Wiki zu veröffentlichen.

Anmerkung zur Bearbeitung: Korrekturen von Tippfehlern kann jeder machen. Redaktionelle Änderungen und Erweiterungen aber bitte mit dem Autor (z.B. auf der [[Diskussion:Erste Schritte in FHEM|zugehörigen Diskussionsseite]]) abstimmen.

==Der erste Einstieg==
Um FHEM zum ersten Mal aufzurufen, geben Sie im Browser ein:
<nowiki>http://<ip-Adresse>:8083</nowiki>
also z.B. <nowiki>http://192.168.1.1:8083</nowiki>.
Sie gelangen auf den Startbildschirm:

[[Datei:ErsteSchritteInFhem01.png]]

*Am oberen Bildschirmrand sehen Sie das weiße ''Kommandofeld'', in das Sie Befehle tippen können.
*Links daneben befindet sich ein umrahmtes "+"-Symbol, über das Sie ein mehrzeiliges Eingabefeld erreichen können; mehr dazu später.
*Als ersten Menüpunkt sehen Sie die Schaltfläche ''Save config'', mit der Änderungen so gespeichert werden, dass sie auch nach einem Neustart noch vorhanden sind.
*Außerdem gibt es bereits die Räume ''Unsorted'' und ''Everything'', die wir bald kennenlernen.
*Im unteren Block befinden sich weitere Links, auf die wir später ebenfalls eingehen.

Der Hinweis ''Security Check'' besagt, dass Sie noch kein Passwort für FHEM eingerichtet haben. Wie man einen Passwortschutz einrichten kann, steht im Detail in der FHEM-Befehlsreferenz {{Link2CmdRef|Lang=de|Anker=allowed}}, in der es übrigens eine Beschreibung zu allen Funktionen und Modulen von FHEM gibt. Um diese Meldung erst einmal zu unterdrücken, geben Sie in das Kommandofeld ein:
attr global motd none
und bestätigen Ihre Eingabe mit der {{Taste|Enter}}-Taste oder klicken alternativ einfach auf den gleichnamigen Link.

[[Datei:ErsteSchritteInFhem02.png]]

==Device anlegen - define==

Das Grundgerüst von FHEM sind "devices". Typische Devices sind beispielsweise Funksteckdosen, Rolladenmotoren, Temperaturmessgeräte, Magnetventile usw. Aber andere Dinge, die man auf den ersten Blick nicht als physisches Gerät bezeichnen würde, sind Device: So etwa ist die Benutzeroberfläche von FHEM selbst ein device ("FHEMWEB"), ebenso gibt es Devices ohne physische Geräte, die dazu benutzt werden können, um eine Variable zu speichern. Ein sehr einfaches Device, dummy genannt, legen wir jetzt an.

Das dummy devices ist insofern ein besonderes Objekt, weil es nicht unbedingt ein korrespondierendes physisches Gerät (eine physische Lampe, ein Rolladen, ein Magnetventil) benötigt. So können Sie diese Schritte auch ohne ein Hardware-System durchführen bzw. kann hier eine allgemeine Einführung erfolgen, ohne auf die Unterschiede der einzelnen Hardwaresysteme einzugehen. Ein Dummy-Device sieht auf der FHEM-Oberfläche im Allgemeinen genau so aus, wie ein FHEM-Device zu einem physisch vorhandenen Gerät Ihres Hardwaresystems.

Zunächst legen wir einen Schalter an. Dieser soll einen Lichtschalter an der Wand simulieren. Geben Sie dazu folgenden Befehl in das Kommandofeld ein:
define mySwitch1 dummy
"define" ist der FHEM-Befehl, "mySwitch1" der zukünftige Name des devices und "dummy" bezeichnet den Typ. Die Worte define und dummy gehören zur Befehlssyntax von FHEM und können nicht verändert werden, mySwitch1 ist (mehr oder weniger) frei wählbar. Nach drücken der {{Taste|Enter}}-Taste wird die Detail-Ansicht des neuen FHEM-Device ''mySwitch1'' angezeigt.

[[Datei:ErsteSchritteInFhem03.png]]

{{Hinweis|Jedes Device hat genau einen "Typ". Dieser Typ legt gleichzeitig die Perl-Befehlsdatei (man spricht präziser vom "Modul") fest, in der bestimmte Routinen und Eigenschaften festgehalten sind. Ist etwa ein Device vom Typ dummy, so weiß FHEM, dass die Routinen und Eigenschaften im Modul 98_dummy.pm liegen. (Die Zahl 98 hatte früher eine Bedeutung, heute ist das nicht mehr der Fall, aus historischen Gründen wird sie aber immer noch verwendet.)}}
{{Hinweis|Diese Einleitung soll Ihnen ein Gefühl für die Funktionsweise von FHEM vermitteln, ohne dass Ihnen konkrete physische Geräte (spezielle Funk- oder WLAN-Steckdosen, 433MHz-Sender, Homematic-Lampen, ZWave-Aktoren usw.) zur Verfügung stehen müssen. Um für diesen Kurs ein rein "virtuelles Gerät" nutzen zu können, greifen wir auf ein dummy-device zurück. Ein ''dummy'' wird Ihnen auch später noch häufig begegnen, wenn es darum geht, einen Testaufbau zu erläutern oder zur Steuerung eines Programmablaufs Informationen userseitig verfügbar zu machen. Beachten Sie dabei aber bitte immer, dass Ihnen später auch '''sehr viele andere Möglichkeiten''' offenstehen, um Informationen abzuspeichern, auszuwerten oder anzuzeigen, sobald Sie FHEM-Geräte für physische Hardware angelegt haben. Statt hierfür Geräte des Typs ''dummy'' zu verwenden, wird es für Sie zukünftig häufig übersichtlicher sein, Informationen zu einem Gerät direkt bei diesem zu verwalten. Neben den Attributen und Readings, die die hierfür jeweils genutzen Module bereits automatisch bereitstellen, können Sie z.B. bei allen Devices weitere Attribute (userattr) oder Readings (setreading) selbst in fast beliebigem Umfang generieren und darin Ihre eigenen Informationen bereitstellen.}}

Devices haben einen "Zustand", der sich im Zeitablauf ändert und den FHEM registriert. So ist beispielsweise ein Fenster offen, ein Rolladenpanzer geschlossen und eine Funksteckdose hat Spannung. Ein Zustand muss dabei nicht exakt eine Variable beinhalten (Fenster entweder "offen" oder "geschlossen"), ein Zustand kann auch durch mehrere Variablen beschrieben werden (der Zustand eines Raspberry-Systems, device-type sysmon, umfasst beispielsweise die CPU-Frequenz, die CPU-Temperatur, den load und vieles mehr).

Dieser Zustand wird in FHEM durch insgesamt drei Größen erfasst. Diese Größen heißen Internals, Attribute und Readings. Es wäre jetzt zu früh, auf die Bedeutung der drei Begriffe im Detail einzugehen, aber folgende Anmerkungen sind für die nachfolgenden Schritte wichtig:
*''Internals'' enthalten ganz grundlegende Informationen zu dem device. Sie werden vom Nutzer in den seltensten Fällen direkt bearbeitet (meist nur bei der Einrichtung des devices).
*''Attribute'' sollen das Verhalten des devices steuern. Sie können vom Anwender typischerweise verändert (oder erst angelegt) werden.
*''Readings'' besitzen im Gegensatz zu den beiden anderen Größen einen Zeitstempel. Hier werden üblicherweise Messwerte des Gerätes erfasst.

Verwirrend für einen Anfänger kann sein, dass manchmal Internals wie auch Readings mit gleichem Namen (STATE und state) existieren können. Allerdings unterscheidet Perl zwischen Groß- und Kleinschreibung!

{{Hinweis|Der Block '''''Internals''''' zeigt immer die grundlegende Ausprägung eines FHEM-device an:
*'''''NAME''''' ist der von Ihnen vergebene Name.
*'''''TYPE''''' ist der Typ des FHEM-device, hier dummy.
*'''''STATE''''' ist der in allen Übersichten angezeigte Status des Geräts. Da noch keine Zuordnung stattgefunden hat, ist dieser zunächst '''''???'''''.}}

==Räume definieren==
Im nächsten Schritt wollen wir Geräte ordnen und geeignet zusammenfassen. Beispielsweise könnten Sie es für sinnvoll erachten, die Geräte, die sich physisch (tatsächlich) in einem Raum befinden, auch in FHEM entsprechend anzuordnen. In einem "Schlafzimmer" sollen dann also entsprechende devices "Rolladen", "Zeitschalter" und "Radios" zu finden sein. Sie können aber auch andere Zuordnungen vornehmen; man könnte etwa alle Messinstrumente wie Thermometer, Stromzähler und Feuchtigkeitsfühler in einem (eventuell nur logisch und nicht physisch existierenden) Raum "Messinstrumente" erfassen. Der Name eines Raumes ist dabei beliebig.

Um dies zu tun, müssen Sie allen devices, die zum Raum gehören sollen, ein "Attribut" (siehe oben) hinzufügen. Dieses Attribut heißt room und muss als Wert den Namen des Raumes bekommen. Versuchen wir dies für unseren dummy. Hierzu verwenden Sie folgenden Befehl (abschließen der Eingabe mit {{Taste|Enter}}):
attr mySwitch1 room Training

Durch diesen Befehl wird dem Device ''mySwitch1'' das Attribut ''room'' mit dem Wert ''Training'' hinzugefügt. Wieder gehören attr, mySwitch1 und room zur Befehlssyntax von FHEM und können nicht verändert werden, Training ist frei wählbar.

''mySwitch1'' gehört jetzt zum room ''Training''. Durch diese Zuordnung ist dieser Raum in der Navigationsleiste links zur Liste der Räume hinzugefügt worden. Klicken Sie einmal auf den Raum ''Training''.

[[Datei:ErsteSchritteInFhem04.png]]

Es werden nun alle Geräte angezeigt, die diesem Raum zugeordnet wurden. Bisher haben wir hier nur ein Gerät: ''mySwitch1'', unseren dummy.
Neben dem Device-Namen wird immer der Status des Device angezeigt, hier noch ''???''.
Wenn Sie auf den Namen ''mySwitch1'' klicken, gelangen Sie wieder in dessen Detailansicht.

Unser dummy wird in einem Block mit der Typbezeichnung ''dummy'' dargestellt. Diese Typbezeichnung können Sie ebenfalls ändern, wenn Sie ein weiteres Attribut "group" hinzufügen und einen (ebenfalls frei wählbaren) Namen vergeben: Gruppen sortieren devices innerhalb eines Raumes.

Anmerkung: Wenn Sie einen Raum löschen wollen, so tun Sie dies, indem Sie sämtliche devices aus dem Raum entfernen. Für unser Beispiel des Raums ''Training'' bedeutet es, dass in allen devices das Attribut room entfernt wird. Der Raum ''Training'' verschwindet dann von alleine.

==Schaltbefehle definieren==
Nun soll unser ''mySwitch1'' Schalterflächen für ''on'' und ''off'' bekommen.
attr mySwitch1 webCmd on:off

Auch hier handelt es sich um ein Attribut mit dem Namen webCmd und den Werten on:off, das dem device ''mySwitch1'' hinzugefügt wird. Statt den o.g. Befehl in das Kommandofeld einzugeben, können Sie auch im unteren Bereich der Detailansicht das gewünschte Attribut (hier: '''''webCmd''''') auswählen und in dem Textfeld rechts daneben die gewünschten Werte eintragen, hier '''''on:off'''''. Schließen Sie Ihre Eingabe durch Klick auf den Button {{Taste|attr}} ab.

[[Datei:ErsteSchritteInFhem05.png]]

Klicken Sie nun wieder links auf den Raum ''Training''.

Sie sehen, dass durch die Attribut-Angabe im vorhergehenden Schritt nun in der Raumansicht die Schaltflächen für ''on'' und ''off'' hinzugekommen sind.

[[Datei:ErsteSchritteInFhem06.png]]

Klicken Sie versuchsweise auf ''on'' und ''off'': Statt der bisher angezeigten ''???'' erscheint nun ein Glühbirnensymbol, das den aktuellen Status darstellt.

Wenn Sie durch Klicken auf den Device-Namen ''mySwitch1'' wieder in die Detailansicht wechseln, sehen Sie, dass im Block ''Internals'' nun auch der aktuelle Zustand ''STATE'' angezeigt wird. Dieser wird in der Raumansicht als Icon (Glühbirne) dargestellt.

[[Datei:ErsteSchritteInFhem07.png]]

Auch sehen Sie im Detail-Bildschirm einen neuen Block ''Readings''.

Schalten Sie ''mySwitch1'' noch einmal aus. Achten Sie beim Schalten auf die Readings: Neben dem Internal ''STATE'' gibt es ein Reading gleichen Namens, das aber (siehe oben: Grundbegriffe; Perl unterscheidet zwischen Groß- und Kleinschreibung) mit einem Zeitstempel versehen ist. Prüfen Sie, ob das Reading ''state'' incl. seines Zeitstempels aktualisiert wurde.

==Event monitor==

Devices kommunizieren über so genannte ''Events'' (Ereignisse) miteinander. Ein device sendet ein Event an FHEM und FHEM verteilt dieses Event an alle devices. Diese devices wiederum entscheiden dann, ob und wie sie auf das Event reagieren. Das Verständnis von Events und wie sie aufgebaut sind ist elementar und wir werden sie noch oft benötigen. Wir wollen daher Events ein wenig näher kennenlernen und uns dazu den Eventmonitor anschauen. Dieser Eventmonitor zeigt alle aktuellen Events in FHEM an.

Öffnen Sie dazu in Ihrem Browser ein zusätzliches Fenster, in dem Sie neben FHEM den '''[[Event monitor]]''' anzeigen. Am schnellsten geht das, indem Sie mit der rechten Maustaste auf ''Event monitor'' klicken und aus dem Kontextmenü des Browsers ''Öffnen in neuem Fenster'' auswählen. Legen Sie die Fenster so übereinander, dass Sie gleichzeitig den Event monitor sehen und Ihren ''mySwitch1'' bedienen können. Unter Windows ab Version 7 geht das am Einfachsten, wenn Sie zuerst das eine Fenster aktivieren und {{Taste|Windows}}+{{Taste|Pfeil rechts}} drücken, anschließend das selbe mit dem anderen Fenster und {{Taste|Windows}}+{{Taste|Pfeil links}} wiederholen.

[[Datei:ErsteSchritteInFhem08.png]]

Schalten wir ''mySwitch1'', so löst unser device ein Event aus und FHEM verteilt es an alle anderen devices. Bei jeder Betätigung des Schalters erscheint ein neues Event im ''Event monitor''. Probieren Sie auch, was passiert, wenn Sie zweimal hintereinander auf ''on'' klicken.

Im Eventmonitor wird ein Event immer durch einen Zeitstempel beschrieben. Es folgen der Typ des auslösenden Gerätes (hier ''dummy''), der Name des Device, welches das Ereignis auslöst (hier ''mySwitch1'') und zuletzt der ausgelöste Befehl (hier ''on'' oder ''off'').

Andere FHEM-Geräte (beispielsweise eine Fernbedienung oder ein Funkschalter an der Wand) erzeugen bei jedem Tastendruck oder bei Klick einen Event. Diese Events erscheinen ebenfalls im Event monitor.

==Schalten von Geräten - set==
''mySwitch1'' kann also über Klicken auf ''on'' oder ''off'' geschaltet werden. Alternativ geht das auch über die Eingabe eines Befehls in das Kommandofeld.

Geben Sie dazu in das Kommandofeld <code>set mySwitch1 on</code> oder <code>set mySwitch1 off</code> ein und bestätigen jeweils mit der {{Taste|Enter}}-Taste. Auch hierbei ändert sich der Schaltzustand und ein Event wird ausgelöst. Den ''set''-Befehl werden wir ebenfalls noch häufig verwenden.

Für weitere Tests legen wir nun ein neues Device '''''myLamp1''''' an. Diese wollen wir später mit '''''mySwitch1''''' bedienen.
define myLamp1 dummy
Da dies eine Lampe, also einen Aktor darstellen soll, werden wir der Lampe selbst keine Buttons für ''on'' oder ''off'' geben.

Die Lampe soll im Training stehen. Diese Zuordnung könnten Sie wie zuvor über die Kommandozeile erreichen. Diesmal sind wir aber tippfaul und möchten die Zuordnung durch Klicken vornehmen.

Da ''myLamp1'' noch keinem Raum zugeordnet ist, erscheint sie im Raum ''Unsorted''. Wechseln Sie in diesen Raum und klicken Sie auf den Namen von ''myLamp1'', um in die Detailansicht zu gelangen.

[[Datei:ErsteSchritteInFhem09.png]]

Im unteren Bereich können wir wieder die Attributzuordnung vornehmen.

Praktischerweise ist das Attribut ''room'' bereits ausgewählt. Bei einem Klick in das Eingabefeld neben ''room'' öffnet sich eine Dialogbox mit allen in FHEM bereits angelegten Räumen. Durch Anklicken der Raumnamen können Sie ein oder mehrere Räume auswählen. Wählen Sie den Raum ''Training'' aus und bestätigen Sie die Dialogbox mit OK. Der ausgewählte Raum wird in das Eingabefeld übernommen und Sie müssen nur noch auf den Button {{Taste|attr}} klicken.

Wechseln Sie nun wieder in den Raum ''Training''. Es werden beide Geräte angezeigt.

[[Datei:ErsteSchritteInFhem10.png]]

==Bei Event ausführen - notify==

Im nächsten Schritt werden wir FHEM beibringen, auf einen Event von ''mySwitch1'' zu reagieren. Im Beispiel soll immer dann, wenn ''mySwitch1'' einen Event mit dem Befehl ''on'' auslöst, das Gerät ''myLamp1'' eingeschaltet werden.

Dazu wird in FHEM ein "notify" verwendet. Die Befehlsstruktur ist
define <NAME> notify <REGEXP> <command>
Diese Befehlsstruktur besteht erkennbar aus drei Teilen.

*Der Name '''<NAME>''' dient später dazu, dieses FHEM-Device anzeigen und wiederfinden zu können. Als Name verwende ich hier ''n_mySwitch1_on'', also ''n_'' um es als Notify kenntlich zu machen, dann das auslösende Gerät ''mySwitch1'' und den auslösenden Event ''on''. Sie können das notify ganz nach Gusto ''n1'' nennen oder ''Karlheinz''. Mein Name scheint auf den ersten Blick kompliziert, ist aber hilfreich, wenn Sie später mehrere Notify angelegt haben. Device-Namen dürfen aus den Zeichen '''a-z''', '''A-Z''', '''0-9''', '''Unterstrich _''' und '''Punkt .''' bestehen, wobei ein Punkt nicht an erster Stelle stehen darf. Sie werden später sehen, dass der Punkt in perl und damit FHEM eine besondere Bedeutung hat, wenn möglich sollten Sie daher auf seine Verwendung in Device-Namen verzichten.
*'''<REGEXP>''' steht für "Regular Expression" (auch reguläre Ausdrücke) und definiert die Bedingung, wann das Notify ausgeführt werden soll. Hierauf gehen wir gleich genauer ein, da reguläre Ausdrücke in perl und FHEM sehr häufig verwendet werden.
*'''<command>''' definiert, was denn eigentlich ausgeführt werden soll. In unserem Beispiel soll das <code>set myLamp1 on</code> sein.

Reguläre Ausdrücke dienen dazu, bestimmte (syntaktische) Eigenschaften von Zeichenketten zu beschreiben. So kann man mit Hilfe eines Regex beispielsweise prüfen, ob ein bestimmtes Wort in einer Zeichenkette enthalten ist oder ob es nicht in der Zeichenkette vorkommt, man kann Zahlen in einer Zeichenkette identifizieren und vieles mehr. Sie werden sich mit Regex später detaillierter auseinandersetzen dürfen :)

Wann immer in FHEM ein Event auftritt, wird dieses an alle notifies weitergeleitet. Jedes Notify prüft nun, ob es auf das Ereignis reagieren soll. Das geschieht, indem mit Hilfe reguläre Ausdrücke geprüft wird, ob das gerade weitergeleitete Event den oben genannten Befehl auslösen soll. Man spricht auch davon dass geprüft wird, ob Ereignis und notify "matchen". In unserem Fall löst ''mySwitch1'' ein Event mit dem Befehl ''on'' aus. Um dieses Event "abzufangen" und darauf zu reagieren, wird für die Regular Expression die Schreibweise <code>mySwitch1:on</code> verwendet. In einem notify werden Events also dadurch abgefangen, indem wir das device (auf das reagiert werden soll) und der Befehl (auf den reagiert wird) durch einen Doppelpunkt trennen. Diese Syntax gilt für alle notifies. (Bei anderen Modulen kann es sein, dass Events durch eine andere Schreibweise "angefangen" werden müssen.)

Unser Notify wird also erstellt mit
define n_mySwitch1_on notify mySwitch1:on set myLamp1 on

Nach Eingabe dieses Befehls in das Kommandofeld, abgeschlossen durch {{Taste|Enter}}, sehen Sie wieder die Detailansicht des neuen FHEM-Device, also des Notify (siehe TYPE).

[[Datei:ErsteSchritteInFhem11.png]]

Im Block ''Internals'' sehen Sie hier die Definition '''DEF'''. Angezeigt wird hier alles, was bei der Definition nach dem Wort "notify", also nach dem Gerätetyp angegeben wurde. Es erscheinen also ''<regexp>'' und ''<command>''.
{{Hinweis|Im Block '''''Probably associated with''''' werden alle FHEM-Devices angezeigt, die mit dem Notify verbunden sind. Die Geräte werden als klickbare Device-Namen angezeigt. Das ist praktisch, da man so mit einem Klick zur Detailansicht des jeweiligen Geräts springen kann.}}

Ordnen Sie auch das Notify unserem Training zu (im unteren Bereich das Attribut ''room'' und den passenden Raum auswählen und dann auf ''attr'' klicken).

Wenn Sie nun im FHEM-Menü auf ''Training'' klicken, werden unsere drei FHEM-Devices angezeigt.

[[Datei:ErsteSchritteInFhem12.png]]

{{Hinweis|Üblicherweise würde man das Notify keinem Raum zuordnen, da es später für den Benutzer gar nicht sichtbar sein soll. Für unsere Testdurchläufe ist es aber praktischer.}}

Wenn Sie nun ''mySwitch1'' auf ''on'' schalten, wird auch ''myLamp1'' auf ''on'' geschaltet. Das funktioniert scheinbar nur beim ersten Mal – wenn Sie aber den Event Monitor prüfen oder in der Detailansicht von ''myLamp1'' auf den Zeitstempel der letzten Statusänderung schauen, werden Sie sehen, dass es jedes Mal ausgeführt wird.

Damit das Ganze auch beim Ausschalten funktioniert, legen Sie ein zweites notify an:
define n_mySwitch1_off notify mySwitch1:off set myLamp1 off
Funktioniert es wie erwartet?

Natürlich möchte man nicht für jeden Befehl, den ein Device auslöst, ein eigenes Notify anlegen. Es geht auch einfacher.
Statt
define n_mySwitch1_on notify mySwitch1:on set myLamp1 on
define n_mySwitch1_off notify mySwitch1:off set myLamp1 off
definieren wir nun
define n_mySwitch1 notify mySwitch1 set myLamp1 '''$EVENT'''
Wir sehen, dass die Regex nun nicht mehr unterscheidet, ob ''mySwitch1'' den Event ''on'' oder ''off'' sendet. Lassen wir diese Angabe weg, löst dieses Notify bei jedem Event von ''mySwitch1'' aus, egal mit welchem Kommando. Im auszuführenden ''set''-Befehl verwenden wir nun die FHEM-Variable '''$EVENT''' (Groß/Kleinschreibung beachten!). Dies ist ein Platzhalter für den Befehl, der vom auslösenden Event übernommen wird. Wenn also ''mySwitch1'' ein ''on'' auslöst, nimmt '''$EVENT''' den Wert ''on'' an. Entsprechend für ''off'' oder jeden anderen Befehl.

==Devices löschen oder deaktivieren – delete, disable==
Wenn Sie den Event Monitor beachten, werden Sie sehen, dass nach jeder Betätigung von ''mySwitch1'' der Befehl für ''myLamp1'' nun zweimal ausgeführt wird. Das liegt daran, dass auf jeden Event von ''mySwitch1'' zwei Notify reagieren – sowohl die "alten" Notify wie auch das Neue. Um dies zu umgehen, müssen wir die alten Notify loswerden. Dazu gibt es zwei Möglichkeiten.

#Löschen Sie ein Notify mit dem Befehl <code>delete <name></code>, z.B. mit <code>delete n_mySwitch1_on</code>. Der <code>delete</code> Befehl funktioniert übrigens für jedes Objekt in FHEM. Sie können damit also auch "echte" Devices löschen.
#Deaktivieren Sie ein Notify, indem Sie das Attribut ''disable'' verwenden. Das können Sie wieder über die Detailansicht des Notify setzen. Wählen Sie dazu zunächst aus der Drop-Down-Liste rechts neben dem Stichwort {{Taste|attr}} das Attribut ''disable'' aus. Tragen Sie dann in das Eingabefeld ganz rechts den Wert ''1'' ein und zur Bestätigung klicken Sie links auf {{Taste|attr}}. Alternativ dazu geben Sie in der Kommandozeile <code>attr n_mySwitch1_off disable 1</code> ein.

==Save Config==

Wann immer Sie mit dem aktuellen Zustand Ihrer FHEM-Konfiguration zufrieden sind, klicken Sie im FHEM-Menü oben links einmal auf '''''Save config''''' oder geben Sie in das Kommandofeld den Befehl <code>save</code> ein. Ihre Konfiguration wird nun gespeichert. Tun Sie das nicht, sind alle Änderungen nach dem nächsten FHEM-Neustart '''verloren'''. FHEM erinnert Sie deshalb an ungespeicherte Änderungen durch ein rotes Fragezeichen neben '''''Save config'''''.

==Bestehende Devices verändern – modify==

Wir legen nun eine zweite Lampe an, die ebenfalls durch unseren ''mySwitch1'' und unser Notify geschaltet werden soll.
Die neue Lampe wird durch folgende Eingabe in das Kommandofeld erzeugt:
define myLamp2 dummy

Durch "Zusammenklicken" im Detail-Bildschirm von ''myLamp2'' ordnen Sie diese ebenfalls dem Raum ''Training'' zu und weisen ihr über das Attribut ''webCmd'' Schaltflächen für ''on'' und ''off'' zu.

[[Datei:ErsteSchritteInFhem13.png]]

Nun passen wir das Notify ''n_mySwitch1'' an. Dazu navigieren Sie auf den Detail-Bildschirm des Notify: Wechseln Sie in den Raum ''Training'' und klicken Sie auf den Namen von ''n_mySwitch1''.

Im Detail-Bildschirm befindet sich die Zeile ''DEF'', die wir uns vorhin schon einmal angeschaut haben. Wenn Sie auf das Wort ''DEF'' klicken, können Sie die Definition eines FHEM-Objekts bearbeiten.

{{Hinweis|Im Feld ''DEF'' wird nur der Teil der Definition angezeigt, der beim Anlegen dieses Notify nach dem Objekttyp, also ''notify'' folgt. Sie finden hier also zunächst die Regex auf die das Notify reagiert, dann nach einer Leerstelle den auszuführenden Befehl.
Der Lesbarkeit halber ist im Folgenden immer das gesamte define-Statement dargestellt, auch wenn man es im Feld ''DEF'' nicht vollständig sieht.}}

Wir ändern hier also von
define n_mySwitch1 notify mySwitch1 set myLamp1 $EVENT
zu
define n_mySwitch1 notify mySwitch1 set myLamp1,myLamp2 $EVENT

[[Datei:ErsteSchritteInFhem14.png]]

Zum Beenden der Bearbeitung klicken Sie auf die Schaltfläche '''''modify <name>''''', hier also {{Taste|modify n_mySwitch1}}. Wenn Sie die Angaben im Detail-Bildschirm prüfen, sehen Sie, dass die ''DEF''inition des Notify angepasst wurde.

[[Datei:ErsteSchritteInFhem14B.png]]

Beachten Sie auch hier wieder, dass im Detailscreen im unteren Bereich unter ''Probably associated with'' die geschalteten Lampen erscheinen – das wird noch oft nützlich sein.

{{Hinweis|Über den Link '''''Device specific help''''' können Sie sich übrigens den gesamten Hilfe-Text zu Ihrem device-Typ aus der commandref anschauen, hier also den Hilfetext zu ''notify''. Dieser Link ist gerade zu Beginn häufig hilfreich.}}

Nun können Sie testen, ob ein Klick auf ''mySwitch1'' auch wirklich beide Lampen schaltet. Schauen Sie sich dabei auch wieder in einem separaten Fenster mit dem Event Monitor die entstehenden Events an.

[[Datei:ErsteSchritteInFhem15.png]]

==Mehrere Devices schalten==

Zum Schalten mehrerer Devices kann also verwendet werden
set <device1>,<device2> on

Eine alternative Schreibweise dafür ist
set <device1> on; set <device2> on

Auch eine Kombination ist möglich:
set <device1>,<device2> on; set <device3> off

Auch innerhalb eines notify (oder anderen FHEM-Befehlen) kann man mehrere Befehle auflisten, jedoch ist hier eines zu beachten:
define n1 notify mySwitch1:on set myLamp1 on;set myLamp2 off
Die Befehle sind durch ein Semikolon getrennt. Effekt ist: Das notify schaltet myLamp1 wann immer mySwitch1 den Event on sendet. Der nächste Befehl in dieser Zeile ist ''set myLamp2 off''. Dieser wird '''sofort''' bei der Eingabe der o.g. Befehlszeile abgearbeitet. Es schaltet also myLamp2 sofort, myLamp1 erst nach dem Event von mySwitch1.

Soll auch der zweite Befehl ''set myLamp2 off'' erst nach dem Event ausgeführt werden, muss ein doppeltes Semikolon genutzt werden:
define n1 notify mySwitch1:on set myLamp1 on;;set myLamp2 off

Die kombinierte Variante könnte so aussehen:
define n1 notify mySwitch1:on set myLamp1 on;;set myLamp2 off;set myLampe3 on
Diese Befehlszeile würde also myLampe3 sofort schalten, aber erst nach dem Event von mySwitch1 schalten myLamp1 und myLamp2.

==Devices umbenennen==

Schließlich wollen wir (zur Übung) noch ein Device umbenennen: Aus '''''myLamp2''''' soll '''''myStandardLamp''''' werden. Dafür verwenden wir
rename <alterName> <neuerName>

Hierbei ist zu beachten, dass zugehörige notify-Anweisungen '''nicht''' automatisch aktualisiert werden. Beachten Sie also vor dem Umbenennen im unteren Bereich des Detail-Bildschirms die Liste ''Probably associated with'', damit Sie bei der folgenden Anpassung keines Ihrer Notify vergessen.

Geben Sie also in das Kommandofeld ein
rename myLamp2 myStandardLamp
und passen Sie anschließend ''n_mySwitch1'' an, indem Sie auf dessen Detail-Bildschirm im Bereich ''DEF'' die Definition anpassen.

Nach der Änderung muss das Notify lauten
define n_mySwitch1 notify mySwitch1 set myLamp1,myStandardLamp $EVENT

[[Datei:ErsteSchritteInFhem16.png]]

==Zeitgesteuert schalten - at==

Im nächsten Schritt soll eine Zeitsteuerung eingerichtet werden.
Zunächst möchten wir erreichen, dass ''myLamp1'' nach einer Minute ausgeschaltet wird wie z.B. ein Treppenhauslicht.

{{Hinweis|Damit Sie den Effekt sehen können, schalten Sie ''myLamp1'' vorher auf ''on''.}}

Für Zeitsteuerungen gibt es den FHEM-Device-Typ ''at''. Die Befehlsstruktur ist
define <name> at <timespec> <command>
'''<name>''' und '''<command>''' haben hier dieselbe Funktion wie bei notify. Neu ist hier lediglich '''<timespec>''' (time specification), also die Zeitangabe. Diese erfolgt in der Schreibweise ''HH:MM:SS'' oder ''HH:MM''.

Um '''''myLamp1''''' also '''in einer Minute auszuschalten''', erzeugen Sie folgendes ''at'':
define a_myLamp1 at +00:01:00 set myLamp1 off

[[Datei:ErsteSchritteInFhem17.png]]

Probieren Sie es aus.
Wird ''myLamp1'' nach einer Minute ausgeschaltet?
Wird dabei ein Event erzeugt?

Wenn Sie sich die Detailansicht des ''at'' anschauen möchten, müssen Sie sich übrigens beeilen: Nach der einmaligen Ausführung wird das ''at'' automatisch gelöscht. Falls FHEM schneller war, können Sie es ja noch einmal anlegen und ggf. eine längere Zeitspanne angeben :-)

Bei <timespec> kann man die Sekunden auch weglassen und einfach nur HH:MM schreiben. Außerdem gibt es mehrere Varianten:
{|class="wikitable"
|+Varianten von Zeitangaben für ''at''
|-
!Notation
!Erklärung
|-
|style="text-align: right;"|+00:02:00
|In zwei Minuten; einmalige Ausführung
|-
|style="text-align: right;"|00:02:00
|Um zwei Minuten nach Mitternacht, also um 00:02 Uhr und 0 Sekunden; einmalige Ausführung
|-
|style="text-align: right;"|*00:02:00
|Täglich um 00:02 Uhr
|-
|style="text-align: right;"|+*00:02:00
|Alle 2 Minuten
|-
|style="text-align: right;"|+*{3}00:02
|Dreimal, alle zwei Minuten
|-
|style="text-align: right;"|*{3}00:02
|Dreimal um 00:02 Uhr
|-
|style="text-align: right;"|*{sunset_rel()}
|Täglich zu Sonnenuntergang
|-
|style="text-align: right;"|*{sunrise(+120)}
|Täglich 2 Minuten (120 Sekunden) nach Sonnenaufgang
|}
*Durch die Angabe von '''*''' wird also eine dauerhafte Wiederholung definiert. Die Wiederholungen laufen so lange, bis das ''at'' gelöscht oder disabled wird.
*Durch die Angabe von '''+''' wird die angegebene Zeit nicht mehr als absolute Uhrzeit interpretiert, sondern als Timer, nach wie vielen Stunden:Minuten:Sekunden der Befehl ausgeführt wird.
*Durch die Angabe von '''''{n}''''' wird das ''at'' nur n-mal durchlaufen.
*Die Funktionen '''''{sunset_rel()}''''' und '''''{sunrise()}''''' liefern die passende Uhrzeit zurück. Durch Angabe von '''''*''''' wird dies täglich wiederholt. Die geschweiften Klammer zeigen an, dass FHEM den Inhalt dieser Klammern direkt als Perl-Funktionen ausführt.

Um bspw. täglich zu Sonnenaufgang die Gartenbeleuchtung auszuschalten, definieren Sie so etwas wie
define a_gardenLight_morning_off at *{sunrise()} set gardenLight off

[[Datei:ErsteSchritteInFhem18.png]]

Im Detailscreen eines ''at'' wird übrigens im ''STATE'' der Zeitpunkt der nächsten Ausführung angezeigt.

Diese Info erscheint auch in der Raum-Ansicht, falls Sie das ''at'' dort anzeigen lassen:

[[Datei:ErsteSchritteInFhem18B.png]]

==Timer bei einem Event starten - notify und at==
{{Randnotiz|RNText='''Zeit- und Ereignissteuerung mit DOIF'''
Seit Erscheinen des ursprünglichen Artikels Anfang 2014 ist eine weitere Möglichkeit der Zeit- und Ereignissteuerung eingeführt worden.

Siehe: [[DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erläuterungen#Erste_Schritte_mit_DOIF:_Zeit-_und_Ereignissteuerung|'''Erste Schritte mit DOIF: Zeit- und Ereignissteuerung''']]

Der Autor des ursprünglichen Artikels hat freundlicherweise zugestimmt diesen Artikel mit einem Link zu ergänzen.}}
Als letzte Übung wollen wir ein ''notify'' und ein ''at'' verbinden. Der Timer soll nun nicht starten, wenn Sie den Befehl in das Kommandofeld eingeben, sondern wenn ein Event eintritt.

[[Datei:GotoRAW-Import firststeps.PNG|thumb|left|300px]]Dazu basteln wir uns ein Stairwell: Legen Sie dafür die Dummy-Devices ''sw_Switch'' und ''sw_Light'' im Raum ''Stairwell'' an. Um die folgenden Befehle an einem Stück eingeben zu können, klicken Sie auf das umrahmte "+"-Symbol neben der Kommandozeile (Nur im Standard Style f18 vorhanden - beachten Sie dazu diesen Artikel [[Import_von_Code_Snippets]]), fügen die folgenden Zeilen mit copy&paste in das daraufhin erscheinende Dialogfeld ein und drücken auf {{Taste|Execute}}:

define sw_Switch dummy
attr sw_Switch room Stairwell
attr sw_Switch webCmd on
define sw_Light dummy
attr sw_Light room Stairwell
[[Datei:RAW-Import firststeps.PNG]]

Anschließend können Sie das Dialogfeld wieder schließen oder auch die nachfolgenden Befehle darüber eingeben. Beachten Sie, dass mit ''Execute'' alle Anweisungen aus dem Dialogfeld ausgeführt werden, was ggf. zu Fehlermeldungen führen kann, wenn z.B. ein Gerät bereits definiert ist. Zeilen mit Anweisungen, die bereits in die Konfiguration übernommen wurden, können Sie daher getrost löschen, um solche Effekte zu vermeiden.

Nun fehlt noch das Notify, welches auf ''sw_Switch:on'' reagiert und daraufhin zwei Befehle ausführt:
*Einschalten des Treppenhauslichts mit <code>set sw_Light on</code>
*Einen Timer starten, der es nach einer Minute wieder ausschaltet. Also <code>define a1 at +00:01 set sw_Light off</code>.

Das sieht dann so aus (und muss ins Kommandofeld als '''eine''' Zeile eingegeben werden):
define n_sw_Switch_on notify sw_Switch:on
set sw_Light on;;define a1 at +00:01 set sw_Light off
Beim Auslösen des Notify wird also als Kommando das Einschalten des Treppenhauslichts ausgelöst, wie auch das Definieren eines Timers, der es eine Minute später wieder ausschaltet.
Funktioniert es?

[[Datei:ErsteSchritteInFhem19.png]]

Da das ja doch recht sperrig ist, gibt es noch eine etwas einfachere Alternative:
define n_sw_Switch_on notify sw_Switch:on set sw_Light on;;sleep 60;;set sw_Light off

Manche Hardwaresysteme bieten auch den Befehl ''on-for-timer'', mit dem man alternativ schreiben kann
define n_sw_Switch_on notify sw_Switch:on set sw_Light on-for-timer 60

==Wie geht es weiter?==

Sie haben nun kennengelernt:
* Das Anlegen von FHEM-Devices mit '''define'''
* '''Events''' und den Event-Monitor
* Schalten von Devices mit '''set'''
* Verändern von Devices mit '''modify''', '''rename''' und '''delete'''
* Das Setzen und Bearbeiten von '''Attributen'''
* Event-getriebene Aktionen durch '''notify'''
* Zeitgesteuertes Schalten mit '''at'''

Damit kennen Sie die grundlegendsten Mechanismen von FHEM. Details zu diesen Befehlen finden Sie in der FHEM Befehlsreferenz {{Link2CmdRef}}.

'''Tipp:''' Zu vielen FHEM-Befehlen und Gerätetypen gibt es auch eine deutschsprachige Beschreibung. Klicken Sie dazu in der commandref oben links auf den Link "DE".

In der commandref finden Sie neben der Beschreibung aller FHEM-Befehle auch die Liste aller Gerätetypen, die in FHEM eingebunden werden können.

Sie werden feststellen, dass "echte" FHEM-Devices grundsätzlich genau so aussehen, wie die dummy-Devices, die Sie hier bereits kennengelernt haben. Der wesentliche Unterschied ist, dass Sie die verfügbaren Befehle nicht mehr selbst mittels ''attr webCmd'' festlegen müssen, da diese bereits durch das FHEM-Device vorgegeben sind. Und Events werden nicht nur ausgelöst, wenn Sie im FHEM-Webfrontend klicken, sondern auch, wenn das physische Gerät (also der Bewegungssensor oder der Lichtschalter an der Wand) auslöst.

Sobald Sie ihre ersten Geräte an FHEM gekoppelt haben, schauen Sie sich den Event-Monitor an, um zu sehen, wann welche Events ausgelöst werden.

Einen umfangreicheren Einstieg in FHEM finden Sie im Dokument [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung-mit-FHEM]

Die für FHEM wichtigen Grundlagen der Programmiersprache Perl kann man in den ersten Kapiteln eines Perl-Buches oder diversen frei im Internet verfügbaren Perl-Tutorials nachlesen.

Viel Spaß und Erfolg mit FHEM !

[[Kategorie:HOWTOS]]

Diskussion:Erste Schritte in FHEM

2024-11-22T13:55:55Z

Afo-solar: Neuer Abschnitt /* Attribut "disable" */

== Die Sache mit dem doppelten Semikolon ==

Gerade für den Anfänger an den sich dieses Dokument richtet, wäre es sehr wichtig zu verstehen, warum das Semikolon verdoppelt werden muss und was damit geschieht (''es wird nur einfach in DEF gespeichert''). Das wird hier nur anhand des daraus resultierenden Symptoms erklärt: "Sofort ausführen oder später". Aber das warum wäre m.E. gerade hier für das Verständnis beim Einstieg wichtig. Ansonsten ist es auch schwer nachzuvollziehen, warum man den gleichen Befehl den <code>notify</code> ausführen soll auf der Kommandozeile mit verdoppeltem Semikolon und beim editieren des Internals DEF dann wieder ohne Verdoppelung schreiben muss. Drei Überlegungen dazu:
# Könnte man das Beispiel mit der Verdoppelung noch um das Editieren des Internals DEF erweitern und dabei genau das erläutern. Ohne diese Erkenntnis ist die Tücke dieses Konstrukts schwer verständlich und der Anfänger wundert sich warum seine Lampe auf den Status <code>on; define a1 at +00:01 set myLampe1,myLampe2 off</code> o.Ä. gesetzt wird.
# Gibt es überhaupt sinnvolle Fälle, in denen ein verdoppeltes Semikolon im DEF benötigt wird. Spätestens bei dem hier benötigten vierfach Semikolon sollte man wissen was damit wann geschieht.
# Gibt es sinnvolle Zustände die ein Semikolon enthalten? Wäre da eine Warnung möglich?
Viele Grüße --[[Benutzer:MGu|MGu]] ([[Benutzer Diskussion:MGu|Diskussion]]) 18:10, 17. Apr. 2016 (CEST)

== Falsche und indirekte negative Darstellung von notify/at im Vergleich zu DOIF ==

Hallo!

Die bewertende Aussage "Bei der Kombination von Ereignis (Bewegungsmelder meldet eine Bewegung) und Zeitangaben werden die stärken des DOIF deutlich. Es ist nur eine Definition (Gerät) notwendig. Wollte man dies durch die Verwendung von at und notify lösen, wären mehrere Definitionen notwendig oder ausreichende Perl-Kenntnisse." insbesondere im Zusammenhang mit dem Beispiel halte ich für falsch und bringt Einsteiger auf eine vollkommen falsche Spur/Sichtweise.

Die nur zeitweise Ausführung eines notify bzw. at erreicht man durch Setzen des Attributes <code>disabledForIntervals</code>. Damit muss man für die Umsetzung des Beispiels beim notify nur das passende Zeitintervall im genannten Attribut setzen. Es sind keine weiteren Definitionen notwendig.

Wenn der DOIF-Abschnitt erhalten bleiben soll und meine Aussage richtig ist, dann bitte ich um kurzfristige Entfernung der Wertung und auch Darstellung der Lösung des erweiterten Beispiels mit einem notify und dem Attribut disabledForIntervals. Das Wiki sollte nach Möglichkeit eine neutrale Sichtweise vermitteln, wenn es nicht eindeutige Vor- oder Nachteile gibt, die ich hier nicht erkenne.

Da es sich um einen wichtigen Artikel handelt, werde ich spätestens morgen selbst Änderungen vornehmen, um nicht Einsteigern falsche Sichtweisen zu vermitteln.

Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 09:43, 12. Feb. 2017 (CET)
<hr />
:Bin auch für "rückgängig machen", insbesondere auch, da diese Seite auf dem Einsteigerdokument von Uli Maass basiert und nur mit seinem Einverständnis ins Wiki übernommen wurde. Darüber hinaus ist die DOIF-Ergänzung sicherlich als redaktionelle Erweiterung anzusehen und allein aus diesem Gesichtspunkt schon mit Uli abzustimmen. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:20, 13. Feb. 2017 (CET)
<hr>
::Jep, war auch mein erster Gedanke --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 09:27, 13. Feb. 2017 (CET)
<hr>
:::Habe die Änderungen komplett zurückgesetzt.
:::Begründung:
:::* die vergleichenden Aussagen sind falsch
:::* ein Einverständnis der redaktionellen Änderung liegt afaik nicht vor und die Änderung wurde hier nicht vorab diskutiert. (den Hinweis darauf im Vorspann des Artikels hatte ich zuvor übersehen)
:::Wiedereinbau ist nach Abstimmung mit Uli und mit korrekter Darstellung nach Review grundsätzlich möglich. Dazu Änderungsvorschläge hier auf der Diskussionsseite einstellen.
:::--[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 09:48, 13. Feb. 2017 (CET)
Ist der Abstimmungsvorbehalt nicht unzulässig? Oder gilt der Hinweis über dem Speichern-Button nicht für Alle Wiki-Benutzer "Falls du nicht möchtest, dass deine Arbeit hier von anderen verändert und verbreitet wird, dann klicke nicht auf „Seite speichern“."

Die vergleichenden Passagen werde ich ändern.

--[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 12:10, 13. Feb. 2017 (CET)
<hr>
:Hmm, diese Seite ist einfach ein Sonderfall. Uli Maas hat da ursprünglich ein PDF-Dokument erstellt, das lange als Einstiegslektüre zu FHEM gehandelt wurde. Ich habe nur damals nach Rücksprache mit ihm die Erlaubnis bekommen, das PDF ins Wiki zu übernehmen. Die "Rechte" liegen aber sozusagen immer noch bei Uli. Deswegen habe ich das extra in der Einleitung erwähnt. Sowie auch diesen Punkt: "Redaktionelle Änderungen und Erweiterungen aber bitte mit dem Autor (z.B. auf der zugehörigen Diskussionsseite) abstimmen."
:Wie gesagt, ein Sonderfall. Bitte nicht persönlich nehmen.
:--[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 12:52, 13. Feb. 2017 (CET)
<hr>
:
:Hallo!
:Abstimmungsvorbehalt liest sich hart :-) . Es ist eine Bitte, die Du wahrscheinlich übersehen hast, und die in diesem Fall (Artikel) ihre Begründung hat. Das ist ein wichtiger Grundlagenartikel der überall verlinkt wird und darum richtig und objektiv sein soll. Der Inhalt wurde zuvor von mehreren Personen reviewed. Änderungen sollten daher vorher abgesprochen und besprochen werden, damit sie auch richtig sind.
:Hätte ich den Artikel nicht auf der oberen Beobachtungsprioriät, wäre vielleicht falsches Wissen verbreitet worden und das ist für niemanden sinnvoll. Genau darum habe ich auch die schnelle Reaktion angekündigt und umgesetzt.
:Das Problem der Änderung durch jedermann ist auch ein Aspekt, warum das Einsteiger-PDF nicht im Wiki steht.
:Ich persönlich denke, dass man gewisse Bitten respektieren sollte. Genauso habe ich damals Damians Bitte respektiert, dass im Wiki die Anwendungsbeispiele zu [[DOIF]] entfernt werden und das umgesetzt. Er stand DOIF-Artikeln im Wiki insgesamt kritisch gegenüber. Deine Artikel zu DOIF wurden auch intern beratschlagt, ob sie im Sinne von Damian "zulässig" sind. Angesichts der sehr guten Qualität und auch Eurer engen Zusammenarbeit bei der Fortentwicklung von DOIF haben wir das als gegeben hingenommen.
:Insgesamt setzen wir im Wiki auf einen großzügiges Rechtesystem ohne Review vor Freigabe. Zudem darf jeder fast jede Seite ändern und anpassen. Bei Besonderheiten -wie hier- werden bisher entsprechende Bitten/Hinweise ausgesprochen, die man einhalten sollte.
:Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:49, 13. Feb. 2017 (CET)

Hallo,
ich bin gerne bereit hier einen Entwurf zum Review einzustellen, damit die Qualität des Artikels gewährleistet bleibt.
DOIF gehört als grundlegendes Automatisierungselement in ein Einstiegsdokument, da stimmst Du mir sicherlich zu.

Wenn Abweichungen zu den Wiki-Lizenzbedingungen mit einzelnen Autoren von euch vereinbart werden, solltet Ihr nicht deren Klärung, Abstimmung u. Einhaltung auf die Benutzer abwälzen, sondern nach dem Verursacherprinzip selbst durchführen. Zumal dem Benutzer nicht ohne Weiteres bekannt ist, unter welchem Avatar er den Autor findet.

Diese Forderung: "und auch Darstellung der Lösung des erweiterten Beispiels mit einem notify und dem Attribut disabledForIntervals." halte ich für pure Willkür, denn das gilt ja nur für mich, solange die anderen Beispiele nicht mit DOIF-Beispielen ergänzt werden. Sie ist sicherlich ähnlich entstanden, wie meine vergleichenden Textpassagen.

Den Absimmungsvorbehalt habe ich so verstanden, als Vorbehalt und ich habe ihn nicht über sehen, sondern ignoriert. Aber nicht ohne auf die Seite von Uli zu schauen, wo Du seit 16:26, 2. Okt. 2015 auf eine Antwort wartest.

'''Hier mein Vorschlag zum Review:'''

== Zeit- und Eventsteuerung, DOIF vereint at und notify ==
Aufgabenstellung: Ein Treppenhauslicht soll durch einen Bewegungsmelder eingeschaltet werden, aber nur zwischen 18 Uhr und 8 Uhr.

Bei der Kombination von [[Event|Ereignis]] (Bewegungsmelder meldet eine Bewegung) und Zeitangaben werden die Stärken des [[DOIF]] deutlich.

Zeitangaben erfolgen im [[DOIF]] in eckigen Klammern <code>[HH:MM]</code> für einen Zeitpunkt und <code>[HH:MM-HH:MM]</code> für eine Zeitspanne.

Hier ist vorausgesetzt, dass der Bewegungsmelder als Gerät mit dem Namen ''BM'' definiert wurde und er ein [[Readings|Reading]] mit dem Namen ''motion'' besitzt. Das [[Readings|Reading]] ''motion'' nimmt bei erkannter Bewegung den Wert ''on'' an und nach Verschwinden der Bewegung den Wert ''off''.
Auf die Statusänderung des Bewegungsmelders wird auch wieder über Angaben in eckigen Klammern <code>[gerätename:readingname]</code> zugegriffen.

Bei erkannter Bewegung soll geschaltet werden, also wenn der Status des BM auf ''on'' wechselt. Dies wird geprüft durch einen vergleichenden [https://de.wikipedia.org/wiki/Operator_(Mathematik) Operator] ''eq'' (equal). Die Zeitangaben und der Ereignisvergleich werden durch den logischen [https://de.wikipedia.org/wiki/Operator_(Mathematik) Operator] ''and'' verknüpft. Der set-Befehl wird ausgeführt, wenn die ganze Bedingung logisch wahr wird, das ist nur der Fall, wenn zwischen 18 Uhr und 8 Uhr eine Bewegung erkannt wird.

Die Definition des [[DOIF]] ist einfach:
<pre>define treppenhaus_di DOIF ([18:00-08:00] and [BM:motion] eq "on") (set th_Licht on-for-timer 60)</pre>
Es sind natürlich auch flexible Zeitangaben möglich, die sich auf den Sonnenauf u. -untergang beziehen.
<pre>define treppenhaus_di DOIF ([{sunset}-{sunrise}] and [BM:motion] eq "on") (set th_Licht on-for-timer 60)</pre>
Es können auch Zeiten angegeben werden, die in [[Readings]] des DOIF-Gerätes selbst stehen und über das WEB-Frontend verändert werden können.
<pre>define treppenhaus_di DOIF ([[$SELF:Beginn]-[$SELF:Ende]] and [BM:motion] eq "on") (set th_Licht on-for-timer [$SELF:Dauer])</pre>
[[Datei:ErsteSchritte DOIF.png]]

Weitere Ausführungen zum DOIF würden den Rahmen der ''ersten Schritte'' sprengen.
Wenn das Interesse an [[DOIF]] geweckt wurde, gibt es im [[DOIF/Labor_-_ausführbare,_praxisnahe_Beispiele_als_Problemlösung_zum_Experimentieren|DOIF Labor]] ausführbare Beispiele zum Importieren über [[Import_von_Code_Snippets|Raw definition]].

'''und die Ergänzung in: ''Sie haben nun kennengelernt:'' '''
* [[DOIF]]: Zusammenfassen von Ereignissteuerung ([[notify]]) und Zeitsteuerung ([[at]])

--[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 16:39, 13. Feb. 2017 (CET)

Ich habe eine Selbstrevision durchgeführt und den obigen Text überarbeitet.

--[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 18:30, 13. Feb. 2017 (CET)
<hr>
:Hallo allerseits,
:vielen Dank für die rege Diskussion zu diesem Artikel.
:In der Tat wär's mir wie geschrieben lieb, wenn redaktionelle Änderungen vor dem Einfügen mit mir abgesprochen würden.
:Bezgl. DOIF: ich kenne das Modul aus Posts und Diskussionen im Forum, nutze es aber selbst nicht und konnte/kann deshalb auch nix dazu schreiben. Insofern vielen Dank für die Zulieferung eines neuen Abschnitts.
:Da diese Anleitung sich speziell an den Einsteiger wendet, der vielleicht das erste mal nen Blick auf FHEM wirft, hab ich mit dem Einbinden des DOIF-Beispiels 2 Sorten Bauchschmerzen:
:1. es zeigt dem Neuling gleich beim allerersten Kontakt mit FHEM mehrere Alternativen für denselben Sachverhalt auf, das hallte ich für verwirrend.
:2. DOIF verwendet eine proprietäre Syntax in regexp - auch diese hat zumindest in der Anfangszeit das Potential, den Neuling zu verwirren.
:Mein Ansatz ist "Einfachheit durch weglassen" - das würde möchte ich auch auf diese Diskussion und mithin DOIF anwenden.
:Vorschlag: aus diesem Artikel rauslassen, aber in die nächste Version des Einsteiger-pdf aufnehmen - das ist ja wesentlich umfangreicher und versucht, möglichst viele hilfreiche Module vorzustellen und z.T. auch zu erklären - dort wäre so ein DOIF-Artikel m.E. wesentlich besser aufgehoben.
:Wenn ich endlich mal zur besagten nächsten Version komme, melde ich mich wieder mit der Bitte um input.
: Gruß und schönen Tag allerseits, Uli
:--[[Benutzer:Uli|Uli]] ([[Benutzer Diskussion:Uli|Diskussion]]) 09:12, 19. Feb. 2017 (CET)

<hr>
::Hallo Uli,
::ich habe die Bedenken hinsichtlich einer Ergänzung des Einsteigerartikels in meiner Naivität unterschätzt.
::Gegen die Abstimmung einer Ergänzung habe ich selbstverständlich nichts einzuwenden.
::Ich stehe voll hinter Deinem Ansatz "Einfachheit durch weglassen". Deshalb schlage ich vor, die Beispiele, die at und notify verwenden durch DOIF zu ersetzen, dann wird dem Einsteiger nur ein Modul zugemutet. Das ist möglich, weil durch DOIF die Angabe generischer Auslöser vereinfacht und harmonisiert wurde. DOIF funktioniert ohne Kenntnis "regulärer Ausdrücke".
::* Angabe eines Auslösers: <code>[<name>:<reading>] vs. <name>:<reading>.*</code>, eine einfache Readingsangabe reicht im DOIF
::* Angabe eines Zeitpunktes: <code>[HH:MM:SS] vs. *HH:MM:SS</code>,
::* und Angabe einer Zeitspanne, die einen Neustart überlebt: <code>[HH:MM:SS-HH:MM:SS] vs. *HH:MM:SS ...;;define at *HH:MM:SS ...</code>

::Diese wegweisende, von Dir als properitär bezeichnete Syntax, hat den Set-Befehl beeinflusst, bekannt als ''set magic'' <code>set <name> [<gerät>:<reading>]</code>.

::Wenn Du die Regexp-Syntax im DOIF als properitär bezeichnest, dann trifft das vielmehr auch auf die Syntax von at und notify zu, beim notify werden z.B. intern die Begrenzungszeichen ^ und $ gesetzt, ohne es in der Befehlereferenz zu erwähnen.
::Beispiel
::Ausgehend von den Events
<pre>
2017-02-21 19:25:09 dummy du3 B: off
2017-02-21 19:25:10 dummy du3 B: on
</pre>
::würde ich eine exakte Regexp so formulieren <code>^du3$:^B: (on|off)$</code>. Das funktioniert im notify nicht, im DOIF schon, also nur mal zum Thema "properitäre Syntax".

::Hier mein Gegenvorschlag: DOIF statt at und notify in die "ersten Schritte" aufnehmen.

::Dieser Vorschlag folgt Deinem Ansatz "Einfachheit durch weglassen" zielführend, daher bitte ich Dich diesen Vorschlag anzunehmen.

::DOIF ins Einsteiger-pdf aufzunehmen ist eine gute Idee, aber das kann ja noch dauern, wie Du selbst andeutest.

::LG Trelle

::--[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 20:22, 21. Feb. 2017 (CET)

Hallo an alle Beteiligten der Disskussion Erste Schritte,

die Antwortzeiten sind hier ja recht lang, da hatte ich Gelegenheit meinen Vorschlag für die Erweiterung der "Ersten Schritte" noch einmal gründlich zu überarbeiten. Es sollte jetzt keine Formulierungen mehr geben, die den Verdacht aufkeimen lassen könnten, dass at und notify nicht gleichberechtigte Partner-Module zu DOIF sein könnten. Damit sind dann auch [[DOIF]], die Befehlsreferenz und dieser Vorschlag harmonisiert.

'''Hier nun der überarbeitete Vorschlag:'''

== Zeit- und Ereignissteuerung mit DOIF ==
'''[[DOIF]]''' (ausgeprochen: du if, übersetzt: tue wenn) ist ein universelles Modul, welches [[Event|ereignis-]] und zeitgesteuert in Abhängigkeit definierter Bedingungen Anweisungen ausführt.

In einer Hausautomatisation geht es immer wieder um die Ausführung von Befehlen abhängig von einem [[Ereignis]]. Oft reicht aber eine einfache Abfrage der Art: "wenn [[Ereignis]] eintritt, dann Befehl ausführen" nicht aus. Ebenso häufig möchte man eine Aktion nicht nur von einem einzelnen [[Ereignis]] abhängig ausführen, sondern abhängig von mehreren Bedingungen, z. B. "schalte Außenlicht ein, wenn es dunkel wird, aber nicht vor 18:00 Uhr" oder "schalte die Warmwasserzirkulation ein, wenn die Rücklauftemperatur unter 38 Grad fällt und jemand zuhause ist". In solchen Fällen muss man mehrere Bedingung logisch miteinander verknüpfen. Ebenso muss sowohl auf Ereignisse wie auch auf Zeittrigger gleichermaßen reagiert werden.

An dieser Stelle setzt das Modul [[DOIF]] an. Es stellt eine eigene Benutzer-Schnittstelle zur Verfügung ohne Programmierkenntnisse in [https://de.wikipedia.org/wiki/Perl_(Programmiersprache) Perl] unmittelbar vorauszusetzen. Mit diesem Modul ist es möglich, sowohl [[Ereignis]]- als auch Zeitsteuerung mit Hilfe logischer Abfragen miteinander zu kombinieren. Damit können komplexere Problemstellungen innerhalb eines [[DOIF]]-Moduls gelöst werden, ohne Perlcode in Kombination mit anderen Modulen programmieren zu müssen.

Das [[DOIF]]-Modul bedient sich selbst des Perlinterpreters, damit sind beliebige logische Abfragen möglich. Logische Abfragen werden in DOIF/DOELSEIF-Bedingungen vornehmlich mit Hilfe von and/or-[https://wiki.selfhtml.org/wiki/Perl/Operatoren Operatoren] erstellt. Diese werden mit Angaben von Stati, [[Readings]], [[Internals]], [[Event|Events]] oder Zeiten kombiniert. Sie werden grundsätzlich in eckigen Klammern angegeben und führen zur Triggerung des Moduls und damit zur Auswertung der dazugehörigen Bedingung. Zusätzlich können in einer Bedingung Perl-Funktionen angegeben werden, die in [[FHEM]] definiert sind. Wenn eine Bedingung wahr wird, so werden die dazugehörigen Befehle ausgeführt.

Die vollständige Dokumentation mit zahlreichen Beispielen ist in der [https://fhem.de/commandref_DE.html deutschsprachigen Befehlsreferenz zum DOIF] zu finden.

Zusätzliche, ausführbare Beispiele zum [[Import von Code Snippets|Import]] in [[FHEM]], gibt es im [[DOIF/Labor - ausführbare, praxisnahe Beispiele als Problemlösung zum Experimentieren|DOIF Labor]]
=== Ereignissteuerung ===
{{Randnotiz|RNText=Hinweis: Verwendung von
* <code>[<Gerätename>:"<Ereignis>"]</code> zur Abfrage eines Ereignisses von einem Gerät
* '''DOELSE''' das Schlüsselwort leitet einen Befehlszweig ohne explizite Bedingung ein. Dieser Zweig wird ausgeführt, wenn keine geprüfte Bedingung wahr ist.
* '''devStateIcon''' zum direkten Ausführen eines Befehls im [[DOIF]] und zur Anzeige von Icons
}}
Aufgabenstellung: Eine Fernbedienung soll einen Fernseher einschalten, der über eine Funkstekdose angeschlossen ist.

Das Gerät '''Fernbedienung''' wird durch den Dummy '''remotecontrol''' dargestellt. In der Realität könnte es die Definition eines Empfängers für eine Infrarot-Fernbedienung sein.

Das Gerät '''Funksteckdose TV''' wird durch den Dummy '''tv''' dargestellt. In der Realität könnte es die Definition einer Intertechno-Funkstekdose aus dem Baumarkt sein.

Die Signale von '''remotecontrol''' werden über das DOIF '''di_rc_tv''' alias '''Steuerlogik''' in einen Befehl für die Funksteckdose '''tv''' umgesetzt.

Das Signal ist als [[Ereignis]] im [[Event monitor|Event-Monitor]] sichtbar <code>2017-02-28 09:07:03 dummy tv on</code>

Das [[DOIF]] reagiert durch die Angabe von <code>[remotecontrol:"on"]</code> in der Schaltbedingung. Weil '''on''' als Wert in dem Ereignis enthalten ist, wird die Bedingung wahr. Das bewirkt das Ausführen des Befehls <code>set tv on</code>. Danach nimmt das [[DOIF]] den Status '''cmd_1''' an.

Falls '''off''' im Ereignis enthalten ist wird die Bedingung nicht wahr, daher wird der Befehl <code>set tv off</code> des DOELSE-Zweiges des [[DOIF]] ausgeführt und [[DOIF]] nimmt den Status '''cmd_2''' an.

Definition:
<pre>define di_rc_tv DOIF ([remotecontol:"on"]) (set tv on) DOELSE (set tv off)</pre>

Über das [[Attribute|Attribut]] '''devStateIcon''' können die Befehle des [[DOIF]] direkt ausgeführt werden.
<pre>attr di_rc_tv devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1</pre>

Das erste Tripel <code>cmd_1:general_an:cmd_2</code> hat die Bedeutung ''aktueller Status''''':'''''Icon-Name''''':'''''Status nach Betätigung des Icons''. Also, wenn der Status '''cmd_2''' ist, dann zeige das Icon '''general_an''' und wenn das Icon betätigt wird, dann führe den Befehl aus, der zu '''cmd_1''' gehört.

Das zweite Tripel hat die gleiche Funktion, jedoch wird in diesem Fall das Icon '''general_aus''' angezeigt, wenn der Status des [[DOIF]] '''cmd_1''' ist oder '''initialized'''.

Die nachstehende, komplette Definition für die Gruppe A) kann über '''[[Import von Code Snippets|Raw definition]]''' in [[FHEM]] importiert werden.
<pre>
defmod di_rc_tv DOIF ([remotecontrol:"on"]) (set tv on) DOELSE (set tv off)
attr di_rc_tv alias Steuerlogik
attr di_rc_tv devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1
attr di_rc_tv group A) Fernbedienung (Ereignissteuerung)
attr di_rc_tv icon helper_doif
attr di_rc_tv room Schulungsraum

defmod remotecontrol dummy
attr remotecontrol alias Fernbedienung
attr remotecontrol devStateIcon .*:noIcon
attr remotecontrol group A) Fernbedienung (Ereignissteuerung)
attr remotecontrol icon it_remote
attr remotecontrol room Schulungsraum
attr remotecontrol webCmd on:off

defmod tv dummy
attr tv alias Funksteckdose TV
attr tv devStateIcon on:it_television@red off:it_television@blue
attr tv group A) Fernbedienung (Ereignissteuerung)
attr tv icon it_television
attr tv room Schulungsraum
save
</pre>
=== Zeitsteuerung ===
{{Randnotiz|RNText=Hinweis: Verwendung von
* <code><nowiki>[<Zeitpunkt>|<Wochentagangabe>]</nowiki></code> zur Angabe eines Zeitpunktes mit Wochentagbeschränkung (8 ≙ werktags, 7 ≙ Wochenende).
* '''DOELSEIF''' das Schlüsselwort leitet einen Bedingungszweig ein und muss eine Bedingung enthalten. Dieser Zweig wird ausgeführt, wenn eine Bedingung geprüft wird und sie wahr ist.
* '''devStateIcon''' zum direkten Ausführen eines Befehls im [[DOIF]] und zur Anzeige von Icons
}}
Aufgabenstellung: Ein Radio soll werktags und am Wochenende zu unterschiedlichen Zeiten ein- u. ausgeschaltet werden.

Das Gerät '''Funksteckdose Radio''' wird durch den Dummy '''radio''' dargestellt. In der Realität könnte es die Definition einer Intertechno-Funkstekdose aus dem Baumarkt sein.

Wenn die Uhrzeit mit einem Schaltzeitpunkt übereinstimmt, wird die Zeitpunktangabe wahr. Wird dann auch die gesamte Bedingung wahr, dann wird der zu diesem Bedingungszweig gehörende Befehl ausgeführt. Das [[DOIF]] '''di_clock_radio''' alias '''Zeitschaltuhr''' setzt dann einen Befehl zum Schalten der Funksteckdose '''radio''' ab.

Das Zeitereignis ist im [[Event monitor|Event-Monitor]] nicht sichtbar.

Die Zeitpunkte eines Bedingungszweiges sind '''or'''(oder) verknüpft. Im ersten Bedingungszweig steht die Einschaltbedingung, im Zweiten (DOELSEIF) die Auschaltbedingung.

Definition:
<pre>define di_clock_radio DOIF ([06:30|8] or [08:30|7]) (set radio on) DOELSEIF ([08:00|8] or [09:30|7]) (set radio off)</pre>

Über das [[Attribute|Attribut]] '''devStateIcon''' können die Befehle des [[DOIF]] über das WEB-Frontend unabhängig von den Schaltzeitpunkten ausgeführt werden.
<pre>attr ddi_clock_radio devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1</pre>

Die nachstehende, komplette Definition für die Gruppe B) kann über '''[[Import von Code Snippets|Raw definition]]''' in [[FHEM]] importiert werden.
<pre>
defmod di_clock_radio DOIF ([06:30|8] or [08:30|7]) (set radio on) DOELSEIF ([08:00|8] or [09:30|7]) (set radio off)
attr di_clock_radio alias Zeitschaltuhr
attr di_clock_radio devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1
attr di_clock_radio group B) Zeitschaltuhr (Zeitsteuerung)
attr di_clock_radio icon helper_doif
attr di_clock_radio room Schulungsraum

defmod radio dummy
attr radio alias Funksteckdose Radio
attr radio devStateIcon on:it_radio@red off:it_radio@blue
attr radio group B) Zeitschaltuhr (Zeitsteuerung)
attr radio icon it_radio
attr radio room Schulungsraum
save
</pre>

=== Kombinierte Ereignis- und Zeitsteuerung ===
{{Randnotiz|RNText=Hinweis: Verwendung von
* <code><nowiki>[<Beginzeitpunkt>-<Endzeitpunkt>]</nowiki></code> zur Angabe einer Zeitspanne.
* <code>[<Gerätename>:<Reading-Name>]</code> zur Abfrage eines Reading-Inhaltes.
* <code> < </code>, eines numerischen Vergleichsoperators und Vergleich mit einer Konstanten (40).
* '''DOELSE''' das Schlüsselwort leitet einen Befehlszweig ohne explizite Bedingung ein. Dieser Zweig wird ausgeführt, wenn keine geprüfte Bedingung wahr ist.
* '''devStateIcon''' zum direkten Ausführen eines Befehls im [[DOIF]] und zur Anzeige von Icons
* '''readingList''', '''setList''' und '''webCmd''' zur Erzeugung eines Eingabeelementes im Frontend
* '''stateFormat''' um einen benutzerdefinierten Status zu erzeugen.
}}
Aufgabenstellung: Eine Lampe soll in einer Zeispanne eingeschaltet werden, wenn die Helligkeit einen bestimmten Wert unterschreitet.

Das Gerät '''Lampe''' wird durch den Dummy '''lamp''' dargestellt. In der Realität könnte es die Definition einer funkgesteuerten Lampenfassung sein.

Das Gerät '''Helligkeitssensor''' wird durch den Dummy '''sensor''' dargestellt. In der Realität könnte es die Definition eines Homematic Funk-Lichtsensor sein oder ein selbstgebauter Helligkeitssensor mit TSL2561-Chip.

Wenn die aktuelle Uhrzeit in der angegebenen Zeitspanne liegt, ist die Zeitspanne wahr. Wenn dann auch die Helligkeit unter 40 sinkt, wird die gesamte Bedingung wahr, weil Zeitspanne und Hellikeitsvergleich '''and'''(und) verknupft sind. Der zu diesem Bedingungszweig gehörende Befehl wird dann ausgeführt. Das [[DOIF]] '''di_lamp''' alias '''Lampenlogik''' setzt dann einen Befehl zum Schalten der Lampe '''lamp''' ab.
Der DOELSE-Zweig wird ausgeführt, wenn die Bedingung im ersten Zweig unwahr wird.

Definition:
<pre>define di_lamp DOIF ([06:00-19:00] and [sensor:brightness] < 40) (set lamp on) DOELSE (set lamp off)</pre>

Über das [[Attribute|Attribut]] '''devStateIcon''' können die Befehle des [[DOIF]] über das WEB-Frontend unabhängig von den Schaltzeitpunkten ausgeführt werden.
<pre>attr di_lamp devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1</pre>

Das [[Attribute|Attribut]] '''setList''' zusammen mit '''readingList''' und '''webCmd''' realisiert im Gerät '''sensor''' für das Reading '''brightness''' einen Schieberegler, mit dem eine Helligkeit zwischen 0 und 100 in in Schritten von 1 simuliert werden kann und der im Frontend angezeigt wird.
<pre>
attr sensor readingList brightness
attr sensor setList brightness:slider,0,1,100
attr sensor webCmd brightness
</pre>

Mit dem [[Attribute|Attribut]] '''stateFormat''' wird im Gerät '''sensor''' das Reading '''brightness''' in den Status geschrieben. Damit wird der Helligkeitswert auch im Frontend sichtbar.
<pre>
attr sensor stateFormat brightness</pre>

Die nachstehende, komplette Definition für die Gruppe C) kann über '''[[Import von Code Snippets|Raw definition]]''' in [[FHEM]] importiert werden.
<pre>
defmod di_lamp DOIF ([06:00-19:00] and [sensor:brightness] < 40) (set lamp on) DOELSE (set lamp off)
attr di_lamp alias Lampenlogik
attr di_lamp devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1
attr di_lamp group C) Kombinierte Ereignis- und Zeitsteuerung
attr di_lamp icon helper_doif
attr di_lamp room Schulungsraum

defmod lamp dummy
attr lamp alias Lampe
attr lamp group C) Kombinierte Ereignis- und Zeitsteuerung
attr lamp icon light_light
attr lamp room Schulungsraum

defmod sensor dummy
attr sensor alias Helligkeitssensor
attr sensor group C) Kombinierte Ereignis- und Zeitsteuerung
attr sensor icon message_light_intensity
attr sensor readingList brightness
attr sensor room Schulungsraum
attr sensor setList brightness:slider,0,1,100
attr sensor stateFormat brightness
attr sensor webCmd brightness
save
</pre>

=== Ansicht der Gruppen A) bis C) im Frontend ===

[[Datei:erste_schritte_DOIF.png|670px]]

'''und die Ergänzung in: Sie haben nun kennengelernt:'''

* DOIF: Ereignis-und Zeitsteuerung

LG --[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 19:16, 1. Mär. 2017 (CET)

<hr>
:Hi Trelle,
:die langen Antwortzeiten liegen im Wesentlichen daran, dass ich keine Mailbenachrichtigung kriege, wenn hier was geschrieben wird. (vielen Dank an Christian für den Hinweis)
:Mach doch aus der DOIF-Ausarbeitung eine separate Wiki-Seite. Am Ende der Erste-Schritte-Abschnitte zu notify und at können wir dann nen Hinweis einfügen à la: "Hinweis: Als Alternative zu den Befehlen <at|notify> gibt es auch das Modul DOIF, mit dem vor allem komplexere Bedingungen einfacher abzubilden sind."
: Gruß und schönen Tag, Uli
:--[[Benutzer:Uli|Uli]] ([[Benutzer Diskussion:Uli|Diskussion]]) 09:12, 19. Feb. 2017 (CET)

{{Anker|neue_Antwort}}
::Hallo Uli,

::Es geht nicht darum, dass im Wiki etwas über DOIF geschrieben wird, da gibt es schon eine Menge.

::Es geht darum, Einsteigern beim Erstkontakt über die "Ersten Schritte ..." eine ernstzunehmende Möglichkeit der Zeit- und Eventverarbeitung nicht vorzuenthalten, sondern Sie auf Augenhöhe anzubieten.

::Das Verschweigen dieser Möglichkeit lässt Einsteiger nicht Ihren besten Weg finden und kommt einer Bevormundung gleich.

::Die Disskussion um at, notify und DOIF lässt 3 Gruppierungen erkennen at/notify bzw. DOIF Puristen und die Mischer. Es gibt keinen Grund anzunehmen, dass diese Vorlieben nicht auch bei Einsteigern angelegt sind.

::Gerade als Marketing Verantwortlicher des Vereins solltest Du ein Interesse haben, allen Gruppen einen leichten Einstieg zu ermöglichen, auch mit Blick auf die sich ankündigende Verbreitungsoffensive (FHEM-Livesystem und Showcases, usw.)

::Du kennst DOIF, nicht hast Du erwähnt, dass sollte Dich nicht abhalten es dennoch ernstzunehmen und von eigenen Vorlieben unabhängig zu betrachten, um den Mehrwert für FHEM erkennen zu können.

::Zur Verkürzung der Antwortzeiten könnten wir die Disskussion auch ins Forum verlagern. Was hältst Du davon?

::LG --[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 12:27, 4. Mär. 2017 (CET)
{{Anker|neue_Antwort}}
:::Hallo Trelle,
:::offengestanden hab ich gar keine Lust auf diese Diskussion.
:::Offenbar haben wir hier unterschiedliche Ansichten. Ich respektiere Deine, respektiere Du bitte meine.
:::Einen Link auf eine DOIF-Seite können wir wie oben vorgeschlagen gerne einbauen, mehr Veränderung möchte ich an diesem Artikel nicht vornehmen.
:::Gruß, Uli
:::PS: Mit meiner Rolle im Verein hat das nix zu tun, es geht ja nicht um ein Vereinsthema.
:::--[[Benutzer:Uli|Uli]] ([[Benutzer Diskussion:Uli|Diskussion]]) 09:12, 19. Feb. 2017 (CET)

{{Anker|neue_Antwort1}}
::::Hallo Uli,

::::nachstehend 2 Vorschläge, wie ich einen Verweis auf die Zeit- und Eventsteuerung mit DOIF einbauen möchte.

::::Welchen Vorschlag bevorzugst Du?

::::LG --[[Benutzer:Trelle|Trelle]] ([[Benutzer Diskussion:Trelle|Diskussion]]) 18:55, 16. Mär. 2017 (CET)

Vorschlag 1

...
Da das ja doch recht sperrig ist, gibt es noch eine etwas einfachere Alternative:
define n_th_Schalter_on notify th_Schalter:on set th_Licht on;;sleep 60;;set th_Licht off

Manche Hardwaresysteme bieten auch den Befehl ''on-for-timer'', mit dem man alternativ schreiben kann
define n_th_Schalter_on notify th_Schalter:on set th_Licht on-for-timer 60

=== Zeit- und Ereignissteuerung mit DOIF ===
Seit erscheinen des ursprünglichen Artikels Anfang 2014, ist eine neue Möglichkeit der Zeit- und Ereignissteuerung eingeführt worden.

Siehe: [[DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erläuterungen#Erste_Schritte_mit_DOIF:_Zeit-_und_Ereignissteuerung|'''Erste Schritte mit DOIF: Zeit- und Ereignissteuerung''']]

Der Autor des usprünglichen Artikel hat freundlicherweise zugestimmt den Artikel mit einem Link zu ergänzen.
==Wie geht es weiter?==
...

Vorschlag 2
==Timer bei einem Event starten - notify und at==
{{Randnotiz|RNText='''Zeit- und Ereignissteuerung mit DOIF'''
Seit erscheinen des ursprünglichen Artikels Anfang 2014, ist eine neue Möglichkeit der Zeit- und Ereignissteuerung eingeführt worden.

Siehe: [[DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erläuterungen#Erste_Schritte_mit_DOIF:_Zeit-_und_Ereignissteuerung|'''Erste Schritte mit DOIF: Zeit- und Ereignissteuerung''']]

Der Autor des usprünglichen Artikels hat freundlicherweise zugestimmt den Artikel mit einem Link zu ergänzen.}}

Als letzte Übung wollen wir ein ''notify'' und ein ''at'' verbinden. Der Timer soll nun nicht starten, wenn Sie den Befehl in das Kommandofeld eingeben, sondern wenn ein Event eintritt.

Dazu basteln wir uns ein Treppenhaus: Legen Sie dafür die Dummy-Devices ''th_Schalter'' und ''th_Licht'' im Raum ''Treppenhaus'' an. Zum Anlegen des Raums ''Treppenhaus'' ordnen Sie dem ersten Device den Raum über das Kommandofeld zu, alle weiteren Attribute dann durch Klicken im Detail-Bildschirm:
define th_Schalter dummy
attr th_Schalter room Treppenhaus
attr th_Schalter webCmd on
define th_Licht dummy
attr th_Licht room Treppenhaus
...

<hr>
:Für mich sind beide Varianten ok. Wobei ich nicht sicher bin, ob eine Platzierung unter "Wie geht es weiter?" der Universalität von DOIF nicht gerechter würde. Unter "Timer bei einem Event starten..." wird die Bedeutung mMn ein wenig reduziert. Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:04, 29. Mär. 2017 (CEST)

== Änderungen am Artikel "Erste Schritte in FHEM" ==
Betrifft folgende Änderungen des Users Andies: https://wiki.fhem.de/w/index.php?title=Erste_Schritte_in_FHEM&type=revision&diff=21496&oldid=21488

Diskussion wurde nachträglich zur besseren Nachvollziehbarkeit von [[Benutzer_Diskussion:Andies]] hierin verlagert. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 10:41, 12. Mai 2017 (CEST)

[[Benutzer_Diskussion:Andies]] schlägt vor, diesen Abschnitt zu löschen. Die Sachen sind ja (in meinen Augen) umgesetzt und durch, momentan müllt das nur die Diskussionsseite zu. Was meint Ihr? --[[Benutzer:andies|Andreas]] 08:21, 03. März 2019 (CEST)
<hr />
:''Dagegen'' - Für weitere / andere Änderungen kann ja gern (wir üblich) ein neuer Abschnitt begonnen werden. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 16:46, 3. Mär. 2019 (CET)

<HR>

Hallo!

Zunächst danke für Deine Mitarbeit am Wiki und bei FHEM. Aber -wie so oft im Leben- gibt es nur Rückmeldungen bei "Problemen" ;-) :

Hast Du Deine Änderungen am Artikel [[Erste Schritte in FHEM]], so wie im Vorwort zum Artikel erbeten, mit dem Verfasser Uli abgestimmt?

Die Änderungen widersprechen deutlich der Intention und dem Konzept des Artikels. Der Artikel soll nur einen kurzen Einstieg in FHEM geben; quasi einen "Vorgeschmack" auf FHEM liefern und nicht das Einsteiger-Pdf ersetzen.

Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:51, 9. Mai 2017 (CEST)

Ja, habe ich abgestimmt. Ich hatte ihm vor einer Woche eine Mail geschrieben und er hat daraufhin OK gesagt, aber darum gebeten, es möglichst kurz zu halten. Kurze Nachfrage: Was genau ist der ''deutliche'' Widerspruch zur Intention?

--[[Benutzer:andies]] 14:09, 9. Mai 2017

<HR>
:Hallo andies!
:[[Erste_Schritte_in_FHEM#Grundbegriffe:_Device_und_Internal.2C_Attribut.2C_Reading]] geht meiner Meinung nach viel zu sehr in die Tiefe und ist gerade für einen groben Überblick nicht notwendig. Finde das persönlich eher verwirrend als hilfreich. Was interessiert mich bspw. beim ersten Kontakt mit FHEM, warum 98 vor einem Modul steht? Wofür muss man das für den schnellen Überblick wissen? Variablen, Zeichenketten, STATE, Readings, Internal, Attribut im "Vorwort" als Grundbegriffe schrecken mich ab. Das kommt doch im Artikelverlauf von selbst und muss man nicht schon im Vorhinein lesen. Der "device"-Erläuterung kann ich hingegen eine gewisse Notwendigkeit abgewinnen.
:Inhaltlich bin ich nicht im Detail eingestiegen, aber "Readings sollen während der Laufzeit vom Anwender" halte ich als Aussage für sehr gefährlich.
:Erlaube mir mal eine Gegenfrage: Hast Du beim Einstieg das Einsteiger-Pdf gelesen? Oder wie bist Du vorgegangen?
:Wenn Du die Änderungen mit Uli abgestimmt hast, ist das Ok und ich bin ruhig :-).
:Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 15:28, 9. Mai 2017 (CEST)

<HR>
::Danke für die konstruktive Antwort; dann lass uns diskutieren! Ich erzähle mal, wieso ich das geschrieben habe und dann schauen wir, was wir am Ende daraus machen. Das wird jetzt aber ein längerer Text (Wir können das auch im Forum diskutieren, wäre das besser? Wenn ja, dann nimm einfach den Link, den ich da angegeben habe: https://forum.fhem.de/index.php/topic,71397.0.html). Ich habe mit FHEM angefangen, weil ich ein ganz konkretes Problem hatte, dass ich mit anderen Servern nicht habe lösen können (Garage übers Internet schalten, Rolladen auch) und ich glaube, dass das typisch ist - jedenfalls war das der Eindruck, den ich von einem Treffen in Berlin hatte. Dann habe ich die Einsteiger-PDF gelesen und hatte "irgendwie" Ahnung, wie das geht. Dann habe ich meine Rolladen in Griff gehabt und eigentlich wäre dann alles gut gewesen. Wäre ich da stehen geblieben, hätte ich den Wiki-Eintrag ''nicht'' verändert.
:: Der nächste Schritt war dann, dass ich (wie wahrscheinlich einige hier) Blut geleckt hatte. Nun sollte also auch noch der Stromverbrauch erfasst werden etc. Und auf einmal fingen die Probleme an. Ich habe zum Beispiel aus dem Wiki-Eintrag nicht verstanden, was überhaupt ein Attribut ist. Ständig wollte ich mit ReadingsVal die Werte der Attribute auslesen und bekam auch mal den Anpfiff: "Lies mal die commandref". Wenn man aber noch nie mit Perl programmiert hat, kapiert man das auch nach dem zehnten Lesen nicht. Hinzu kommt, dass einige Dinge so erklärt sind, dass für einen Anfänger ein Verständnis nahezu unmöglich wird; einige Wiki-Einträge sind ja wirklich verwaist. Also habe ich überlegt: Warum kapiere ich das nicht? Dann wurde mir klar, weil zum einen recht viele kleine Schusselfehler in der Einleitung stehen (zum Beispiel "Reading 'STATE'", wo es doch ein Internal ist oder man das Reading 'state' meint etc pp - so etwas verwirrt einen Anfänger total!) und zum anderen weil mehrere Grundbegriffe nicht vernünftig erklärt sind (zum Beispiel: "Nur Readings können von Menschen gelesen werden" - Internals auch!). Hinzu kommt, dass in der Einleitung zwar steht, was man genau tun soll ("tipp mal attr XY room sowieso" ein und dann siehst du was), aber nicht erklärt wird, ''was'' man da eigentlich macht - nämlich ein Attribut setzen und einen Wert zuweisen. Deshalb habe ich mich dran gesetzt und überlegt, was '''für mich''' wichtig gewesen wäre.
:: Nun zur Debatte. Was für mich wichtig ist, kann für andere verwirrend sein. Sehe ich sofort ein. Also lass uns im Detail diskutieren, was am Text verändert wird (nochmal: eventuell im Forum?). Das mit der Zeichenkette verstehe ich, das mit den Definitionen der Grundbegriffe finde ich aber wesentlich. Wir sollten vielleicht so debattieren: Was wollen wir beim Anfänger erreichen? Welches Vorwissen müssen wir voraussetzen, was nicht? Ich gehe davon aus, dass der typische Anwender mit einem ganz konkreten Problem zu FHEM stößt und zuerst das gelöst haben will. Dass er wenige Programmierkenntnisse besitzt und auch bereit ist, gewisses Leid in Kauf zu nehmen. Wir können aber nicht voraussetzen (auch wenn das der eine oder andere meint), dass er die gesamte Einsteiger-PDF verstanden, die commandref gelesen und verstanden hat und außerdem mit RegEx problemlos umgehen kann. Wenn wir uns bei der Beschreibung der Person, die den Wiki-Eintrag liest, einig sind, sollte sich ein besserer Text ergeben. Das man dabei sinnvollerweise vermeidet, bereits in der Einleitung eine Debatte zum Sinn und Unsinn von DOIF zu haben, ist auch mir Anfänger klar.
<HR>
:::Zum Diskussionsort: Mir ist es letztlich gleich. Hier wird es vmtl. nur ruhiger und mit weniger Beteiligung als im Forum zu gehen.

:::Also bist Du zum Einstieg mit dem Artikel "Erste Schritte in FHEM" problemlos klargekommen; erst als es weiter in die Tiefe ging, kamen die weiteren Probleme!? Daraus schließe ich zunächst einmal frech, dass der Artikel seinen Zweck erfüllt hat: Ein "Appetitanreger" auf FHEM, der erste Erfolgserlebnisse und erstes Verständniss schafft. Mehr soll er meiner Meinung nach auch nicht. Der Einsteiger soll sich in kurzer Zeit einen Überblick verschaffen (Zeitbedarf max. 60 Minuten): Ist FHEM etwas für mich? Wie geht das grundlegend? Wenn man neugierig geworden ist, dann weiterlernen.

:::Tippfehler und Co. (state vs. STATE) sollten im Artikel natürlich behoben werden. Mit Deinen weiterführenden Erläuterungen insb. Grundbegriffe, die Du nach den ersten Erfolgserlebnissen vermisst hast, steigt der Zeitbedarf für die Durcharbeitung und auch die Komplexität des Artikels deutlich. Er verliert damit eben seine eigentliche Intention. Das, was unter Grundbegriffe steht braucht man zum Einstieg nicht und verwirrt. Er entwickelt sich mMn dadurch in Richtung universellen Einsteiger-PDF Ersatz. Weitergehende Informationen könnte man aus dem Artikel ja verlinken statt sie darin aufzunehmen; aber selbst dabei bin ich zweifelnd, da es schnell zum Verzetteln in Details führt.

:::Auch Deine Definition der Grundbegriffe ist, wie Du im Forum liest, nicht unumstritten. Und die Bedenken kommen nicht von irgendjemanden, sondern von einem der Kern-Developer. Einen Punkt hatte ich gestern auch schon herausgepickt (Readings), den ich persönlich für gefährlich oder eher sogar falsch halte. Zudem existieren schon Definitionen der Begriffe im Wiki, die man verlinken könnte. Warum sollten wir 2 Definitionen im Wiki pflegen? Das ist zu pflegeaufwendig. Das ist aber auch eine Macke von mir: [https://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=prev&oldid=21335] würde ich z.B. nicht so ausführlich machen, sondern auf [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden]] verlinken. Dadurch sind Fehler/Änderungen nur an einer Stelle zu berücksichtigen.

:::Wo steht eigentlich: "Nur Readings können von Menschen gelesen werden" ?

:::Was für Dich wichtig ist, liegt doch an Deinem Wissensstand. Zunächst hat der Einsteiger-Artikel gereicht. Dann ist man weiter und liest das Pdf. Und dann kommen Fragen und noch mehr Fragen. Damit bin ich wieder beim Ausgangspunkt, dass Deine Erläuterungen schon für Fortgeschrittenere sind und nicht in den genannten Artikel sollten ;-).

:::Was ich voraussetze? Nichts außer Lernbereitschaft. Dazu gehört auch, dass man sich zumindest mal Grundzüge von Perl anschaut. (Bin selbst kein Entwickler und werde keiner, sondern nur Anwender) Ohne Regex und Co. ist FHEM schwer "verdaulich". Das z.B. tritt mir mittlerweile zu sehr in den Hintergrund.

:::Mir persönlich wäre es am Liebsten den Einsteiger-Artikel in die Kurzform zurückzubringen und Deine Überlegungen möglichst redudanzfrei in weiterführende Artikel zu packen oder in Ulis Einsteiger-Pdf einzubringen, falls er Hilfe mag. Was ich nicht möchte ist: Dich entmutigen und von der Mitarbeit abbringen, das wird nämmlich schnell so aufgefasst. Und meine Meinung muss auch nicht die Richtige sein, wenn es die überhaut gibt.

:::Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 11:14, 10. Mai 2017 (CEST)

:::PS: (Langfristiges) Ziel ist bspw. [[FHEM_Installation_Windows]] und [[Erste Schritte in FHEM]] so zu gestalten, dass als Einsteiger ein Test von FHEM angefangen bei Installation bis zum Ende der ersten Experimente in ca. 90 Minuten möglich ist.

<HR>

::::Was ist davon zu halten, wenn wir den Grundbegriffe-Artikel zu einem Absatz mit ein, zwei Sätzen zusammenkürzen und den Inhalt auf weiterführende Seiten verschieben? Das wäre dann, in schlechtem Deutsch von der Idee her so: "Also wir legen jetzt mal los und wir brauchen dazu Attribute und Readings (was das ist, kannst du HIER nachlesen), aber erst einmal reicht <XYZ>"? Das können wir bei den anderen Abschnitten, bei denen Du Probleme hast, auch machen. Ich würde mir dann mal was überlegen und das hier vorstellen? Es wäre aber wegen der reparierten Schreibfehler vermutlich einfacher, wenn wir diesen Abschnitt _bearbeiten_ und _nicht_ zurückstellen, denn ich weiß nicht mehr, welche Fehler ich genau geändert habe.

<HR>
:::::Ich mache nichts einfach rückgängig, wir diskutieren doch: Ändere es einfach einmal so ab, wie Du es dann machen würdest. Im Übrigen bin ich nicht der Nabel der Welt, aber habe ein Meinung :-) . Am meisten stören mich die "Grundbegriffe". --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 16:08, 10. Mai 2017 (CEST)
<HR>

::::PS Aus dem Wiki: "Daten, welche von einem Gerät gelesen werden und in FHEM in einer für Menschen verständlichen Form zur Verfügung gestellt werden können, werden Readings genannt". Der Logiker schließt daraus, dass Internals für Menschen nicht verständlich sind (jedenfalls habe ich mich das wirklich gefragt: gilt etwa Readings = UTF-8, Internals = binär o.Ä?!)

<HR>
:::::Halte ich für eine erhebliche Überinterpretation der Aussage. Es wird doch nirgends eine Verbindung oder gar Vergleich zwischen Internals und Readings hergestellt und schon gar nicht, in welcher ihrer Merkmale/Eigenschaften aus Anwendersicht ein Gegensatz besteht. Eine klare und eindeutige Definition der Begriffe ist nicht so einfach und letztlich auch im Fluß. Zudem versuchst Du Begrifflichkeiten, die mMn eher aus Entwicklersicht entstanden sind, in ein Schema der Anwendersicht zu pressen. Ein bedeutendes Gegenbeispiel Deiner Definition finde ich beispielsweise auf die Schnelle noch bei Internals. Du schreibst: "Internals sollen vom Nutzer nicht direkt verändert werden". Das ist so vereinfacht in einem wesentlichen Punkt falsch. Das DEF in den Internals soll gerade von Einsteigern genutzt werden und nicht die manuelle Editierei in der fhem.cfg (siehe bspw. [[Konfiguration#Objektdetails]]). Die Nutzung des DEF wollen wir gerade den Einsteigern krampfhaft vermitteln; jetzt verbieten wir es aber bereits in der Definition im "Vorwort" des Einsteiger-Artikels. Das verwirrt sicherlich. Wenn Du das dann gerade ziehen willst, musst Du noch mehr erklären. Das führt zu mehr Verwirrung. Darum eben besser Definitionen weglassen. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 16:08, 10. Mai 2017 (CEST)
<HR>
::::::Ich habe jetzt erst einmal Änderungen vorgenommen, wie sie hier oben besprochen wurden. Genauer habe ich folgendes gemacht: Ich habe den separaten Abschnitt "Grundbegriffe" entfernt und Teile davon, die nicht technisch sind, in den fortlaufenden Text integriert. Das mit den Zeichenketten habe ich weggelassen. Ansonsten habe ich bei den ersten beiden Befehlen in FHEM etwas mehr Wert darauf gelegt, was man genau da eigentlich eingibt und welche Teile dieser Befehlszeile Syntax sind und wo man (mehr oder weniger) schreiben kann, was man will. --[[Benutzer:andies|Andreas]] ([[Benutzer Diskussion:andies|Diskussion]]) 18:51, 20. Mai 2017 (CEST)

== Attribut "disable" ==

Hallo alle,

zum Einstieg in FHEM habe ich den Text "Erste Schritte in FHEM" gelesen und fand, dass es Spass macht, FHEM so auszuprobieren und fand den Text und die Dummy-Experimente auch ziemlich gut. Ich hatte am Anfang Schwierigkeiten, die Attribute über die Detailansichten zu ändern, am nächsten Tag habe ich dann gemerkt, dass im Text immer steht, dass man auf den Button "attr" klicken soll. Das war also eigene Dummheit ...
Aber an einer Stelle, denke ich sollte der Text geändert werden. Nämlich dort, wo von n_mySwitch1_off das Attribut disable auf 1 gesetzt werden soll. Das geht beim ersten Mal gar nicht über die Detailansicht, da es dort anfangs nicht auftaucht. Daher habe ich den entsprechenden Text geändert auf: "Geben Sie dazu in der Kommandozeile attr n_mySwitch1_off disable 1 ein. Dadurch taucht in der Detailansicht des Notify im unteren Bereich das Attribut disable auf. Dieses kann man nun auf zwei Arten ändern, entweder über die Kommandozeile oder über die Detailansicht (dort den Wert 1 oder 0 auswählen, dann attr klicken)." Ich hoffe das ist ok. Ulrich Maas kann man zur Zeit - soweit ich das verstanden habe - nicht kontaktieren, deshalb habe ich den Änderungsvorschlag direkt in den Text geschrieben.

Grüße
--[[Benutzer:Afo-solar|Afo-solar]] ([[Benutzer Diskussion:Afo-solar|Diskussion]]) 14:55, 22. Nov. 2024 (CET) Felix

Erste Schritte in FHEM

2024-11-22T13:40:09Z

Afo-solar: Das Attribut "disable" ist nicht von Anfang an in der Detailansicht zu sehen, zumindest nicht in der aktuellen Version von fhem. Daher habe ich den Text dahingehend geändert, dass man erst per Kommandozeile, das Attribut auf 1 setzen muss und erst dann in der Detailansicht zwischen den Werten 0 und 1 wählen kann.

Für alle, die das erste mal mit FHEM arbeiten, hier ein kleiner Kurs zum Einstieg.
Dieser ist so aufgebaut, dass man noch keine Hardware benötigt und nach dem Installieren der FHEM-Software sofort loslegen kann.

Diese Anleitung wurde ursprünglich von Ulrich Maass publiziert, der die Genehmigung erteilt hat, sie auch im Wiki zu veröffentlichen.

Anmerkung zur Bearbeitung: Korrekturen von Tippfehlern kann jeder machen. Redaktionelle Änderungen und Erweiterungen aber bitte mit dem Autor (z.B. auf der [[Diskussion:Erste Schritte in FHEM|zugehörigen Diskussionsseite]]) abstimmen.

==Der erste Einstieg==
Um FHEM zum ersten Mal aufzurufen, geben Sie im Browser ein:
<nowiki>http://<ip-Adresse>:8083</nowiki>
also z.B. <nowiki>http://192.168.1.1:8083</nowiki>.
Sie gelangen auf den Startbildschirm:

[[Datei:ErsteSchritteInFhem01.png]]

*Am oberen Bildschirmrand sehen Sie das weiße ''Kommandofeld'', in das Sie Befehle tippen können.
*Links daneben befindet sich ein umrahmtes "+"-Symbol, über das Sie ein mehrzeiliges Eingabefeld erreichen können; mehr dazu später.
*Als ersten Menüpunkt sehen Sie die Schaltfläche ''Save config'', mit der Änderungen so gespeichert werden, dass sie auch nach einem Neustart noch vorhanden sind.
*Außerdem gibt es bereits die Räume ''Unsorted'' und ''Everything'', die wir bald kennenlernen.
*Im unteren Block befinden sich weitere Links, auf die wir später ebenfalls eingehen.

Der Hinweis ''Security Check'' besagt, dass Sie noch kein Passwort für FHEM eingerichtet haben. Wie man einen Passwortschutz einrichten kann, steht im Detail in der FHEM-Befehlsreferenz {{Link2CmdRef|Lang=de|Anker=allowed}}, in der es übrigens eine Beschreibung zu allen Funktionen und Modulen von FHEM gibt. Um diese Meldung erst einmal zu unterdrücken, geben Sie in das Kommandofeld ein:
attr global motd none
und bestätigen Ihre Eingabe mit der {{Taste|Enter}}-Taste oder klicken alternativ einfach auf den gleichnamigen Link.

[[Datei:ErsteSchritteInFhem02.png]]

==Device anlegen - define==

Das Grundgerüst von FHEM sind "devices". Typische Devices sind beispielsweise Funksteckdosen, Rolladenmotoren, Temperaturmessgeräte, Magnetventile usw. Aber andere Dinge, die man auf den ersten Blick nicht als physisches Gerät bezeichnen würde, sind Device: So etwa ist die Benutzeroberfläche von FHEM selbst ein device ("FHEMWEB"), ebenso gibt es Devices ohne physische Geräte, die dazu benutzt werden können, um eine Variable zu speichern. Ein sehr einfaches Device, dummy genannt, legen wir jetzt an.

Das dummy devices ist insofern ein besonderes Objekt, weil es nicht unbedingt ein korrespondierendes physisches Gerät (eine physische Lampe, ein Rolladen, ein Magnetventil) benötigt. So können Sie diese Schritte auch ohne ein Hardware-System durchführen bzw. kann hier eine allgemeine Einführung erfolgen, ohne auf die Unterschiede der einzelnen Hardwaresysteme einzugehen. Ein Dummy-Device sieht auf der FHEM-Oberfläche im Allgemeinen genau so aus, wie ein FHEM-Device zu einem physisch vorhandenen Gerät Ihres Hardwaresystems.

Zunächst legen wir einen Schalter an. Dieser soll einen Lichtschalter an der Wand simulieren. Geben Sie dazu folgenden Befehl in das Kommandofeld ein:
define mySwitch1 dummy
"define" ist der FHEM-Befehl, "mySwitch1" der zukünftige Name des devices und "dummy" bezeichnet den Typ. Die Worte define und dummy gehören zur Befehlssyntax von FHEM und können nicht verändert werden, mySwitch1 ist (mehr oder weniger) frei wählbar. Nach drücken der {{Taste|Enter}}-Taste wird die Detail-Ansicht des neuen FHEM-Device ''mySwitch1'' angezeigt.

[[Datei:ErsteSchritteInFhem03.png]]

{{Hinweis|Jedes Device hat genau einen "Typ". Dieser Typ legt gleichzeitig die Perl-Befehlsdatei (man spricht präziser vom "Modul") fest, in der bestimmte Routinen und Eigenschaften festgehalten sind. Ist etwa ein Device vom Typ dummy, so weiß FHEM, dass die Routinen und Eigenschaften im Modul 98_dummy.pm liegen. (Die Zahl 98 hatte früher eine Bedeutung, heute ist das nicht mehr der Fall, aus historischen Gründen wird sie aber immer noch verwendet.)}}
{{Hinweis|Diese Einleitung soll Ihnen ein Gefühl für die Funktionsweise von FHEM vermitteln, ohne dass Ihnen konkrete physische Geräte (spezielle Funk- oder WLAN-Steckdosen, 433MHz-Sender, Homematic-Lampen, ZWave-Aktoren usw.) zur Verfügung stehen müssen. Um für diesen Kurs ein rein "virtuelles Gerät" nutzen zu können, greifen wir auf ein dummy-device zurück. Ein ''dummy'' wird Ihnen auch später noch häufig begegnen, wenn es darum geht, einen Testaufbau zu erläutern oder zur Steuerung eines Programmablaufs Informationen userseitig verfügbar zu machen. Beachten Sie dabei aber bitte immer, dass Ihnen später auch '''sehr viele andere Möglichkeiten''' offenstehen, um Informationen abzuspeichern, auszuwerten oder anzuzeigen, sobald Sie FHEM-Geräte für physische Hardware angelegt haben. Statt hierfür Geräte des Typs ''dummy'' zu verwenden, wird es für Sie zukünftig häufig übersichtlicher sein, Informationen zu einem Gerät direkt bei diesem zu verwalten. Neben den Attributen und Readings, die die hierfür jeweils genutzen Module bereits automatisch bereitstellen, können Sie z.B. bei allen Devices weitere Attribute (userattr) oder Readings (setreading) selbst in fast beliebigem Umfang generieren und darin Ihre eigenen Informationen bereitstellen.}}

Devices haben einen "Zustand", der sich im Zeitablauf ändert und den FHEM registriert. So ist beispielsweise ein Fenster offen, ein Rolladenpanzer geschlossen und eine Funksteckdose hat Spannung. Ein Zustand muss dabei nicht exakt eine Variable beinhalten (Fenster entweder "offen" oder "geschlossen"), ein Zustand kann auch durch mehrere Variablen beschrieben werden (der Zustand eines Raspberry-Systems, device-type sysmon, umfasst beispielsweise die CPU-Frequenz, die CPU-Temperatur, den load und vieles mehr).

Dieser Zustand wird in FHEM durch insgesamt drei Größen erfasst. Diese Größen heißen Internals, Attribute und Readings. Es wäre jetzt zu früh, auf die Bedeutung der drei Begriffe im Detail einzugehen, aber folgende Anmerkungen sind für die nachfolgenden Schritte wichtig:
*''Internals'' enthalten ganz grundlegende Informationen zu dem device. Sie werden vom Nutzer in den seltensten Fällen direkt bearbeitet (meist nur bei der Einrichtung des devices).
*''Attribute'' sollen das Verhalten des devices steuern. Sie können vom Anwender typischerweise verändert (oder erst angelegt) werden.
*''Readings'' besitzen im Gegensatz zu den beiden anderen Größen einen Zeitstempel. Hier werden üblicherweise Messwerte des Gerätes erfasst.

Verwirrend für einen Anfänger kann sein, dass manchmal Internals wie auch Readings mit gleichem Namen (STATE und state) existieren können. Allerdings unterscheidet Perl zwischen Groß- und Kleinschreibung!

{{Hinweis|Der Block '''''Internals''''' zeigt immer die grundlegende Ausprägung eines FHEM-device an:
*'''''NAME''''' ist der von Ihnen vergebene Name.
*'''''TYPE''''' ist der Typ des FHEM-device, hier dummy.
*'''''STATE''''' ist der in allen Übersichten angezeigte Status des Geräts. Da noch keine Zuordnung stattgefunden hat, ist dieser zunächst '''''???'''''.}}

==Räume definieren==
Im nächsten Schritt wollen wir Geräte ordnen und geeignet zusammenfassen. Beispielsweise könnten Sie es für sinnvoll erachten, die Geräte, die sich physisch (tatsächlich) in einem Raum befinden, auch in FHEM entsprechend anzuordnen. In einem "Schlafzimmer" sollen dann also entsprechende devices "Rolladen", "Zeitschalter" und "Radios" zu finden sein. Sie können aber auch andere Zuordnungen vornehmen; man könnte etwa alle Messinstrumente wie Thermometer, Stromzähler und Feuchtigkeitsfühler in einem (eventuell nur logisch und nicht physisch existierenden) Raum "Messinstrumente" erfassen. Der Name eines Raumes ist dabei beliebig.

Um dies zu tun, müssen Sie allen devices, die zum Raum gehören sollen, ein "Attribut" (siehe oben) hinzufügen. Dieses Attribut heißt room und muss als Wert den Namen des Raumes bekommen. Versuchen wir dies für unseren dummy. Hierzu verwenden Sie folgenden Befehl (abschließen der Eingabe mit {{Taste|Enter}}):
attr mySwitch1 room Training

Durch diesen Befehl wird dem Device ''mySwitch1'' das Attribut ''room'' mit dem Wert ''Training'' hinzugefügt. Wieder gehören attr, mySwitch1 und room zur Befehlssyntax von FHEM und können nicht verändert werden, Training ist frei wählbar.

''mySwitch1'' gehört jetzt zum room ''Training''. Durch diese Zuordnung ist dieser Raum in der Navigationsleiste links zur Liste der Räume hinzugefügt worden. Klicken Sie einmal auf den Raum ''Training''.

[[Datei:ErsteSchritteInFhem04.png]]

Es werden nun alle Geräte angezeigt, die diesem Raum zugeordnet wurden. Bisher haben wir hier nur ein Gerät: ''mySwitch1'', unseren dummy.
Neben dem Device-Namen wird immer der Status des Device angezeigt, hier noch ''???''.
Wenn Sie auf den Namen ''mySwitch1'' klicken, gelangen Sie wieder in dessen Detailansicht.

Unser dummy wird in einem Block mit der Typbezeichnung ''dummy'' dargestellt. Diese Typbezeichnung können Sie ebenfalls ändern, wenn Sie ein weiteres Attribut "group" hinzufügen und einen (ebenfalls frei wählbaren) Namen vergeben: Gruppen sortieren devices innerhalb eines Raumes.

Anmerkung: Wenn Sie einen Raum löschen wollen, so tun Sie dies, indem Sie sämtliche devices aus dem Raum entfernen. Für unser Beispiel des Raums ''Training'' bedeutet es, dass in allen devices das Attribut room entfernt wird. Der Raum ''Training'' verschwindet dann von alleine.

==Schaltbefehle definieren==
Nun soll unser ''mySwitch1'' Schalterflächen für ''on'' und ''off'' bekommen.
attr mySwitch1 webCmd on:off

Auch hier handelt es sich um ein Attribut mit dem Namen webCmd und den Werten on:off, das dem device ''mySwitch1'' hinzugefügt wird. Statt den o.g. Befehl in das Kommandofeld einzugeben, können Sie auch im unteren Bereich der Detailansicht das gewünschte Attribut (hier: '''''webCmd''''') auswählen und in dem Textfeld rechts daneben die gewünschten Werte eintragen, hier '''''on:off'''''. Schließen Sie Ihre Eingabe durch Klick auf den Button {{Taste|attr}} ab.

[[Datei:ErsteSchritteInFhem05.png]]

Klicken Sie nun wieder links auf den Raum ''Training''.

Sie sehen, dass durch die Attribut-Angabe im vorhergehenden Schritt nun in der Raumansicht die Schaltflächen für ''on'' und ''off'' hinzugekommen sind.

[[Datei:ErsteSchritteInFhem06.png]]

Klicken Sie versuchsweise auf ''on'' und ''off'': Statt der bisher angezeigten ''???'' erscheint nun ein Glühbirnensymbol, das den aktuellen Status darstellt.

Wenn Sie durch Klicken auf den Device-Namen ''mySwitch1'' wieder in die Detailansicht wechseln, sehen Sie, dass im Block ''Internals'' nun auch der aktuelle Zustand ''STATE'' angezeigt wird. Dieser wird in der Raumansicht als Icon (Glühbirne) dargestellt.

[[Datei:ErsteSchritteInFhem07.png]]

Auch sehen Sie im Detail-Bildschirm einen neuen Block ''Readings''.

Schalten Sie ''mySwitch1'' noch einmal aus. Achten Sie beim Schalten auf die Readings: Neben dem Internal ''STATE'' gibt es ein Reading gleichen Namens, das aber (siehe oben: Grundbegriffe; Perl unterscheidet zwischen Groß- und Kleinschreibung) mit einem Zeitstempel versehen ist. Prüfen Sie, ob das Reading ''state'' incl. seines Zeitstempels aktualisiert wurde.

==Event monitor==

Devices kommunizieren über so genannte ''Events'' (Ereignisse) miteinander. Ein device sendet ein Event an FHEM und FHEM verteilt dieses Event an alle devices. Diese devices wiederum entscheiden dann, ob und wie sie auf das Event reagieren. Das Verständnis von Events und wie sie aufgebaut sind ist elementar und wir werden sie noch oft benötigen. Wir wollen daher Events ein wenig näher kennenlernen und uns dazu den Eventmonitor anschauen. Dieser Eventmonitor zeigt alle aktuellen Events in FHEM an.

Öffnen Sie dazu in Ihrem Browser ein zusätzliches Fenster, in dem Sie neben FHEM den '''[[Event monitor]]''' anzeigen. Am schnellsten geht das, indem Sie mit der rechten Maustaste auf ''Event monitor'' klicken und aus dem Kontextmenü des Browsers ''Öffnen in neuem Fenster'' auswählen. Legen Sie die Fenster so übereinander, dass Sie gleichzeitig den Event monitor sehen und Ihren ''mySwitch1'' bedienen können. Unter Windows ab Version 7 geht das am Einfachsten, wenn Sie zuerst das eine Fenster aktivieren und {{Taste|Windows}}+{{Taste|Pfeil rechts}} drücken, anschließend das selbe mit dem anderen Fenster und {{Taste|Windows}}+{{Taste|Pfeil links}} wiederholen.

[[Datei:ErsteSchritteInFhem08.png]]

Schalten wir ''mySwitch1'', so löst unser device ein Event aus und FHEM verteilt es an alle anderen devices. Bei jeder Betätigung des Schalters erscheint ein neues Event im ''Event monitor''. Probieren Sie auch, was passiert, wenn Sie zweimal hintereinander auf ''on'' klicken.

Im Eventmonitor wird ein Event immer durch einen Zeitstempel beschrieben. Es folgen der Typ des auslösenden Gerätes (hier ''dummy''), der Name des Device, welches das Ereignis auslöst (hier ''mySwitch1'') und zuletzt der ausgelöste Befehl (hier ''on'' oder ''off'').

Andere FHEM-Geräte (beispielsweise eine Fernbedienung oder ein Funkschalter an der Wand) erzeugen bei jedem Tastendruck oder bei Klick einen Event. Diese Events erscheinen ebenfalls im Event monitor.

==Schalten von Geräten - set==
''mySwitch1'' kann also über Klicken auf ''on'' oder ''off'' geschaltet werden. Alternativ geht das auch über die Eingabe eines Befehls in das Kommandofeld.

Geben Sie dazu in das Kommandofeld <code>set mySwitch1 on</code> oder <code>set mySwitch1 off</code> ein und bestätigen jeweils mit der {{Taste|Enter}}-Taste. Auch hierbei ändert sich der Schaltzustand und ein Event wird ausgelöst. Den ''set''-Befehl werden wir ebenfalls noch häufig verwenden.

Für weitere Tests legen wir nun ein neues Device '''''myLamp1''''' an. Diese wollen wir später mit '''''mySwitch1''''' bedienen.
define myLamp1 dummy
Da dies eine Lampe, also einen Aktor darstellen soll, werden wir der Lampe selbst keine Buttons für ''on'' oder ''off'' geben.

Die Lampe soll im Training stehen. Diese Zuordnung könnten Sie wie zuvor über die Kommandozeile erreichen. Diesmal sind wir aber tippfaul und möchten die Zuordnung durch Klicken vornehmen.

Da ''myLamp1'' noch keinem Raum zugeordnet ist, erscheint sie im Raum ''Unsorted''. Wechseln Sie in diesen Raum und klicken Sie auf den Namen von ''myLamp1'', um in die Detailansicht zu gelangen.

[[Datei:ErsteSchritteInFhem09.png]]

Im unteren Bereich können wir wieder die Attributzuordnung vornehmen.

Praktischerweise ist das Attribut ''room'' bereits ausgewählt. Bei einem Klick in das Eingabefeld neben ''room'' öffnet sich eine Dialogbox mit allen in FHEM bereits angelegten Räumen. Durch Anklicken der Raumnamen können Sie ein oder mehrere Räume auswählen. Wählen Sie den Raum ''Training'' aus und bestätigen Sie die Dialogbox mit OK. Der ausgewählte Raum wird in das Eingabefeld übernommen und Sie müssen nur noch auf den Button {{Taste|attr}} klicken.

Wechseln Sie nun wieder in den Raum ''Training''. Es werden beide Geräte angezeigt.

[[Datei:ErsteSchritteInFhem10.png]]

==Bei Event ausführen - notify==

Im nächsten Schritt werden wir FHEM beibringen, auf einen Event von ''mySwitch1'' zu reagieren. Im Beispiel soll immer dann, wenn ''mySwitch1'' einen Event mit dem Befehl ''on'' auslöst, das Gerät ''myLamp1'' eingeschaltet werden.

Dazu wird in FHEM ein "notify" verwendet. Die Befehlsstruktur ist
define <NAME> notify <REGEXP> <command>
Diese Befehlsstruktur besteht erkennbar aus drei Teilen.

*Der Name '''<NAME>''' dient später dazu, dieses FHEM-Device anzeigen und wiederfinden zu können. Als Name verwende ich hier ''n_mySwitch1_on'', also ''n_'' um es als Notify kenntlich zu machen, dann das auslösende Gerät ''mySwitch1'' und den auslösenden Event ''on''. Sie können das notify ganz nach Gusto ''n1'' nennen oder ''Karlheinz''. Mein Name scheint auf den ersten Blick kompliziert, ist aber hilfreich, wenn Sie später mehrere Notify angelegt haben. Device-Namen dürfen aus den Zeichen '''a-z''', '''A-Z''', '''0-9''', '''Unterstrich _''' und '''Punkt .''' bestehen, wobei ein Punkt nicht an erster Stelle stehen darf. Sie werden später sehen, dass der Punkt in perl und damit FHEM eine besondere Bedeutung hat, wenn möglich sollten Sie daher auf seine Verwendung in Device-Namen verzichten.
*'''<REGEXP>''' steht für "Regular Expression" (auch reguläre Ausdrücke) und definiert die Bedingung, wann das Notify ausgeführt werden soll. Hierauf gehen wir gleich genauer ein, da reguläre Ausdrücke in perl und FHEM sehr häufig verwendet werden.
*'''<command>''' definiert, was denn eigentlich ausgeführt werden soll. In unserem Beispiel soll das <code>set myLamp1 on</code> sein.

Reguläre Ausdrücke dienen dazu, bestimmte (syntaktische) Eigenschaften von Zeichenketten zu beschreiben. So kann man mit Hilfe eines Regex beispielsweise prüfen, ob ein bestimmtes Wort in einer Zeichenkette enthalten ist oder ob es nicht in der Zeichenkette vorkommt, man kann Zahlen in einer Zeichenkette identifizieren und vieles mehr. Sie werden sich mit Regex später detaillierter auseinandersetzen dürfen :)

Wann immer in FHEM ein Event auftritt, wird dieses an alle notifies weitergeleitet. Jedes Notify prüft nun, ob es auf das Ereignis reagieren soll. Das geschieht, indem mit Hilfe reguläre Ausdrücke geprüft wird, ob das gerade weitergeleitete Event den oben genannten Befehl auslösen soll. Man spricht auch davon dass geprüft wird, ob Ereignis und notify "matchen". In unserem Fall löst ''mySwitch1'' ein Event mit dem Befehl ''on'' aus. Um dieses Event "abzufangen" und darauf zu reagieren, wird für die Regular Expression die Schreibweise <code>mySwitch1:on</code> verwendet. In einem notify werden Events also dadurch abgefangen, indem wir das device (auf das reagiert werden soll) und der Befehl (auf den reagiert wird) durch einen Doppelpunkt trennen. Diese Syntax gilt für alle notifies. (Bei anderen Modulen kann es sein, dass Events durch eine andere Schreibweise "angefangen" werden müssen.)

Unser Notify wird also erstellt mit
define n_mySwitch1_on notify mySwitch1:on set myLamp1 on

Nach Eingabe dieses Befehls in das Kommandofeld, abgeschlossen durch {{Taste|Enter}}, sehen Sie wieder die Detailansicht des neuen FHEM-Device, also des Notify (siehe TYPE).

[[Datei:ErsteSchritteInFhem11.png]]

Im Block ''Internals'' sehen Sie hier die Definition '''DEF'''. Angezeigt wird hier alles, was bei der Definition nach dem Wort "notify", also nach dem Gerätetyp angegeben wurde. Es erscheinen also ''<regexp>'' und ''<command>''.
{{Hinweis|Im Block '''''Probably associated with''''' werden alle FHEM-Devices angezeigt, die mit dem Notify verbunden sind. Die Geräte werden als klickbare Device-Namen angezeigt. Das ist praktisch, da man so mit einem Klick zur Detailansicht des jeweiligen Geräts springen kann.}}

Ordnen Sie auch das Notify unserem Training zu (im unteren Bereich das Attribut ''room'' und den passenden Raum auswählen und dann auf ''attr'' klicken).

Wenn Sie nun im FHEM-Menü auf ''Training'' klicken, werden unsere drei FHEM-Devices angezeigt.

[[Datei:ErsteSchritteInFhem12.png]]

{{Hinweis|Üblicherweise würde man das Notify keinem Raum zuordnen, da es später für den Benutzer gar nicht sichtbar sein soll. Für unsere Testdurchläufe ist es aber praktischer.}}

Wenn Sie nun ''mySwitch1'' auf ''on'' schalten, wird auch ''myLamp1'' auf ''on'' geschaltet. Das funktioniert scheinbar nur beim ersten Mal – wenn Sie aber den Event Monitor prüfen oder in der Detailansicht von ''myLamp1'' auf den Zeitstempel der letzten Statusänderung schauen, werden Sie sehen, dass es jedes Mal ausgeführt wird.

Damit das Ganze auch beim Ausschalten funktioniert, legen Sie ein zweites notify an:
define n_mySwitch1_off notify mySwitch1:off set myLamp1 off
Funktioniert es wie erwartet?

Natürlich möchte man nicht für jeden Befehl, den ein Device auslöst, ein eigenes Notify anlegen. Es geht auch einfacher.
Statt
define n_mySwitch1_on notify mySwitch1:on set myLamp1 on
define n_mySwitch1_off notify mySwitch1:off set myLamp1 off
definieren wir nun
define n_mySwitch1 notify mySwitch1 set myLamp1 '''$EVENT'''
Wir sehen, dass die Regex nun nicht mehr unterscheidet, ob ''mySwitch1'' den Event ''on'' oder ''off'' sendet. Lassen wir diese Angabe weg, löst dieses Notify bei jedem Event von ''mySwitch1'' aus, egal mit welchem Kommando. Im auszuführenden ''set''-Befehl verwenden wir nun die FHEM-Variable '''$EVENT''' (Groß/Kleinschreibung beachten!). Dies ist ein Platzhalter für den Befehl, der vom auslösenden Event übernommen wird. Wenn also ''mySwitch1'' ein ''on'' auslöst, nimmt '''$EVENT''' den Wert ''on'' an. Entsprechend für ''off'' oder jeden anderen Befehl.

==Devices löschen oder deaktivieren – delete, disable==
Wenn Sie den Event Monitor beachten, werden Sie sehen, dass nach jeder Betätigung von ''mySwitch1'' der Befehl für ''myLamp1'' nun zweimal ausgeführt wird. Das liegt daran, dass auf jeden Event von ''mySwitch1'' zwei Notify reagieren – sowohl die "alten" Notify wie auch das Neue. Um dies zu umgehen, müssen wir die alten Notify loswerden. Dazu gibt es zwei Möglichkeiten.

#Löschen Sie ein Notify mit dem Befehl <code>delete <name></code>, z.B. mit <code>delete n_mySwitch1_on</code>. Der <code>delete</code> Befehl funktioniert übrigens für jedes Objekt in FHEM. Sie können damit also auch "echte" Devices löschen.
#Deaktivieren Sie ein Notify, indem Sie das Attribut ''disable'' verwenden. Geben Sie dazu in der Kommandozeile <code>attr n_mySwitch1_off disable 1</code> ein. Dadurch taucht in der Detailansicht des Notify im unteren Bereich das Attribut ''disable'' auf. Dieses kann man nun auf zwei Arten ändern, entweder über die Kommandozeile oder über die Detailansicht (dort den Wert ''1'' oder ''0'' auswählen, dann {{Taste|attr}} klicken).

==Save Config==

Wann immer Sie mit dem aktuellen Zustand Ihrer FHEM-Konfiguration zufrieden sind, klicken Sie im FHEM-Menü oben links einmal auf '''''Save config''''' oder geben Sie in das Kommandofeld den Befehl <code>save</code> ein. Ihre Konfiguration wird nun gespeichert. Tun Sie das nicht, sind alle Änderungen nach dem nächsten FHEM-Neustart '''verloren'''. FHEM erinnert Sie deshalb an ungespeicherte Änderungen durch ein rotes Fragezeichen neben '''''Save config'''''.

==Bestehende Devices verändern – modify==

Wir legen nun eine zweite Lampe an, die ebenfalls durch unseren ''mySwitch1'' und unser Notify geschaltet werden soll.
Die neue Lampe wird durch folgende Eingabe in das Kommandofeld erzeugt:
define myLamp2 dummy

Durch "Zusammenklicken" im Detail-Bildschirm von ''myLamp2'' ordnen Sie diese ebenfalls dem Raum ''Training'' zu und weisen ihr über das Attribut ''webCmd'' Schaltflächen für ''on'' und ''off'' zu.

[[Datei:ErsteSchritteInFhem13.png]]

Nun passen wir das Notify ''n_mySwitch1'' an. Dazu navigieren Sie auf den Detail-Bildschirm des Notify: Wechseln Sie in den Raum ''Training'' und klicken Sie auf den Namen von ''n_mySwitch1''.

Im Detail-Bildschirm befindet sich die Zeile ''DEF'', die wir uns vorhin schon einmal angeschaut haben. Wenn Sie auf das Wort ''DEF'' klicken, können Sie die Definition eines FHEM-Objekts bearbeiten.

{{Hinweis|Im Feld ''DEF'' wird nur der Teil der Definition angezeigt, der beim Anlegen dieses Notify nach dem Objekttyp, also ''notify'' folgt. Sie finden hier also zunächst die Regex auf die das Notify reagiert, dann nach einer Leerstelle den auszuführenden Befehl.
Der Lesbarkeit halber ist im Folgenden immer das gesamte define-Statement dargestellt, auch wenn man es im Feld ''DEF'' nicht vollständig sieht.}}

Wir ändern hier also von
define n_mySwitch1 notify mySwitch1 set myLamp1 $EVENT
zu
define n_mySwitch1 notify mySwitch1 set myLamp1,myLamp2 $EVENT

[[Datei:ErsteSchritteInFhem14.png]]

Zum Beenden der Bearbeitung klicken Sie auf die Schaltfläche '''''modify <name>''''', hier also {{Taste|modify n_mySwitch1}}. Wenn Sie die Angaben im Detail-Bildschirm prüfen, sehen Sie, dass die ''DEF''inition des Notify angepasst wurde.

[[Datei:ErsteSchritteInFhem14B.png]]

Beachten Sie auch hier wieder, dass im Detailscreen im unteren Bereich unter ''Probably associated with'' die geschalteten Lampen erscheinen – das wird noch oft nützlich sein.

{{Hinweis|Über den Link '''''Device specific help''''' können Sie sich übrigens den gesamten Hilfe-Text zu Ihrem device-Typ aus der commandref anschauen, hier also den Hilfetext zu ''notify''. Dieser Link ist gerade zu Beginn häufig hilfreich.}}

Nun können Sie testen, ob ein Klick auf ''mySwitch1'' auch wirklich beide Lampen schaltet. Schauen Sie sich dabei auch wieder in einem separaten Fenster mit dem Event Monitor die entstehenden Events an.

[[Datei:ErsteSchritteInFhem15.png]]

==Mehrere Devices schalten==

Zum Schalten mehrerer Devices kann also verwendet werden
set <device1>,<device2> on

Eine alternative Schreibweise dafür ist
set <device1> on; set <device2> on

Auch eine Kombination ist möglich:
set <device1>,<device2> on; set <device3> off

Auch innerhalb eines notify (oder anderen FHEM-Befehlen) kann man mehrere Befehle auflisten, jedoch ist hier eines zu beachten:
define n1 notify mySwitch1:on set myLamp1 on;set myLamp2 off
Die Befehle sind durch ein Semikolon getrennt. Effekt ist: Das notify schaltet myLamp1 wann immer mySwitch1 den Event on sendet. Der nächste Befehl in dieser Zeile ist ''set myLamp2 off''. Dieser wird '''sofort''' bei der Eingabe der o.g. Befehlszeile abgearbeitet. Es schaltet also myLamp2 sofort, myLamp1 erst nach dem Event von mySwitch1.

Soll auch der zweite Befehl ''set myLamp2 off'' erst nach dem Event ausgeführt werden, muss ein doppeltes Semikolon genutzt werden:
define n1 notify mySwitch1:on set myLamp1 on;;set myLamp2 off

Die kombinierte Variante könnte so aussehen:
define n1 notify mySwitch1:on set myLamp1 on;;set myLamp2 off;set myLampe3 on
Diese Befehlszeile würde also myLampe3 sofort schalten, aber erst nach dem Event von mySwitch1 schalten myLamp1 und myLamp2.

==Devices umbenennen==

Schließlich wollen wir (zur Übung) noch ein Device umbenennen: Aus '''''myLamp2''''' soll '''''myStandardLamp''''' werden. Dafür verwenden wir
rename <alterName> <neuerName>

Hierbei ist zu beachten, dass zugehörige notify-Anweisungen '''nicht''' automatisch aktualisiert werden. Beachten Sie also vor dem Umbenennen im unteren Bereich des Detail-Bildschirms die Liste ''Probably associated with'', damit Sie bei der folgenden Anpassung keines Ihrer Notify vergessen.

Geben Sie also in das Kommandofeld ein
rename myLamp2 myStandardLamp
und passen Sie anschließend ''n_mySwitch1'' an, indem Sie auf dessen Detail-Bildschirm im Bereich ''DEF'' die Definition anpassen.

Nach der Änderung muss das Notify lauten
define n_mySwitch1 notify mySwitch1 set myLamp1,myStandardLamp $EVENT

[[Datei:ErsteSchritteInFhem16.png]]

==Zeitgesteuert schalten - at==

Im nächsten Schritt soll eine Zeitsteuerung eingerichtet werden.
Zunächst möchten wir erreichen, dass ''myLamp1'' nach einer Minute ausgeschaltet wird wie z.B. ein Treppenhauslicht.

{{Hinweis|Damit Sie den Effekt sehen können, schalten Sie ''myLamp1'' vorher auf ''on''.}}

Für Zeitsteuerungen gibt es den FHEM-Device-Typ ''at''. Die Befehlsstruktur ist
define <name> at <timespec> <command>
'''<name>''' und '''<command>''' haben hier dieselbe Funktion wie bei notify. Neu ist hier lediglich '''<timespec>''' (time specification), also die Zeitangabe. Diese erfolgt in der Schreibweise ''HH:MM:SS'' oder ''HH:MM''.

Um '''''myLamp1''''' also '''in einer Minute auszuschalten''', erzeugen Sie folgendes ''at'':
define a_myLamp1 at +00:01:00 set myLamp1 off

[[Datei:ErsteSchritteInFhem17.png]]

Probieren Sie es aus.
Wird ''myLamp1'' nach einer Minute ausgeschaltet?
Wird dabei ein Event erzeugt?

Wenn Sie sich die Detailansicht des ''at'' anschauen möchten, müssen Sie sich übrigens beeilen: Nach der einmaligen Ausführung wird das ''at'' automatisch gelöscht. Falls FHEM schneller war, können Sie es ja noch einmal anlegen und ggf. eine längere Zeitspanne angeben :-)

Bei <timespec> kann man die Sekunden auch weglassen und einfach nur HH:MM schreiben. Außerdem gibt es mehrere Varianten:
{|class="wikitable"
|+Varianten von Zeitangaben für ''at''
|-
!Notation
!Erklärung
|-
|style="text-align: right;"|+00:02:00
|In zwei Minuten; einmalige Ausführung
|-
|style="text-align: right;"|00:02:00
|Um zwei Minuten nach Mitternacht, also um 00:02 Uhr und 0 Sekunden; einmalige Ausführung
|-
|style="text-align: right;"|*00:02:00
|Täglich um 00:02 Uhr
|-
|style="text-align: right;"|+*00:02:00
|Alle 2 Minuten
|-
|style="text-align: right;"|+*{3}00:02
|Dreimal, alle zwei Minuten
|-
|style="text-align: right;"|*{3}00:02
|Dreimal um 00:02 Uhr
|-
|style="text-align: right;"|*{sunset_rel()}
|Täglich zu Sonnenuntergang
|-
|style="text-align: right;"|*{sunrise(+120)}
|Täglich 2 Minuten (120 Sekunden) nach Sonnenaufgang
|}
*Durch die Angabe von '''*''' wird also eine dauerhafte Wiederholung definiert. Die Wiederholungen laufen so lange, bis das ''at'' gelöscht oder disabled wird.
*Durch die Angabe von '''+''' wird die angegebene Zeit nicht mehr als absolute Uhrzeit interpretiert, sondern als Timer, nach wie vielen Stunden:Minuten:Sekunden der Befehl ausgeführt wird.
*Durch die Angabe von '''''{n}''''' wird das ''at'' nur n-mal durchlaufen.
*Die Funktionen '''''{sunset_rel()}''''' und '''''{sunrise()}''''' liefern die passende Uhrzeit zurück. Durch Angabe von '''''*''''' wird dies täglich wiederholt. Die geschweiften Klammer zeigen an, dass FHEM den Inhalt dieser Klammern direkt als Perl-Funktionen ausführt.

Um bspw. täglich zu Sonnenaufgang die Gartenbeleuchtung auszuschalten, definieren Sie so etwas wie
define a_gardenLight_morning_off at *{sunrise()} set gardenLight off

[[Datei:ErsteSchritteInFhem18.png]]

Im Detailscreen eines ''at'' wird übrigens im ''STATE'' der Zeitpunkt der nächsten Ausführung angezeigt.

Diese Info erscheint auch in der Raum-Ansicht, falls Sie das ''at'' dort anzeigen lassen:

[[Datei:ErsteSchritteInFhem18B.png]]

==Timer bei einem Event starten - notify und at==
{{Randnotiz|RNText='''Zeit- und Ereignissteuerung mit DOIF'''
Seit Erscheinen des ursprünglichen Artikels Anfang 2014 ist eine weitere Möglichkeit der Zeit- und Ereignissteuerung eingeführt worden.

Siehe: [[DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erläuterungen#Erste_Schritte_mit_DOIF:_Zeit-_und_Ereignissteuerung|'''Erste Schritte mit DOIF: Zeit- und Ereignissteuerung''']]

Der Autor des ursprünglichen Artikels hat freundlicherweise zugestimmt diesen Artikel mit einem Link zu ergänzen.}}
Als letzte Übung wollen wir ein ''notify'' und ein ''at'' verbinden. Der Timer soll nun nicht starten, wenn Sie den Befehl in das Kommandofeld eingeben, sondern wenn ein Event eintritt.

[[Datei:GotoRAW-Import firststeps.PNG|thumb|left|300px]]Dazu basteln wir uns ein Stairwell: Legen Sie dafür die Dummy-Devices ''sw_Switch'' und ''sw_Light'' im Raum ''Stairwell'' an. Um die folgenden Befehle an einem Stück eingeben zu können, klicken Sie auf das umrahmte "+"-Symbol neben der Kommandozeile (Nur im Standard Style f18 vorhanden - beachten Sie dazu diesen Artikel [[Import_von_Code_Snippets]]), fügen die folgenden Zeilen mit copy&paste in das daraufhin erscheinende Dialogfeld ein und drücken auf {{Taste|Execute}}:

define sw_Switch dummy
attr sw_Switch room Stairwell
attr sw_Switch webCmd on
define sw_Light dummy
attr sw_Light room Stairwell
[[Datei:RAW-Import firststeps.PNG]]

Anschließend können Sie das Dialogfeld wieder schließen oder auch die nachfolgenden Befehle darüber eingeben. Beachten Sie, dass mit ''Execute'' alle Anweisungen aus dem Dialogfeld ausgeführt werden, was ggf. zu Fehlermeldungen führen kann, wenn z.B. ein Gerät bereits definiert ist. Zeilen mit Anweisungen, die bereits in die Konfiguration übernommen wurden, können Sie daher getrost löschen, um solche Effekte zu vermeiden.

Nun fehlt noch das Notify, welches auf ''sw_Switch:on'' reagiert und daraufhin zwei Befehle ausführt:
*Einschalten des Treppenhauslichts mit <code>set sw_Light on</code>
*Einen Timer starten, der es nach einer Minute wieder ausschaltet. Also <code>define a1 at +00:01 set sw_Light off</code>.

Das sieht dann so aus (und muss ins Kommandofeld als '''eine''' Zeile eingegeben werden):
define n_sw_Switch_on notify sw_Switch:on
set sw_Light on;;define a1 at +00:01 set sw_Light off
Beim Auslösen des Notify wird also als Kommando das Einschalten des Treppenhauslichts ausgelöst, wie auch das Definieren eines Timers, der es eine Minute später wieder ausschaltet.
Funktioniert es?

[[Datei:ErsteSchritteInFhem19.png]]

Da das ja doch recht sperrig ist, gibt es noch eine etwas einfachere Alternative:
define n_sw_Switch_on notify sw_Switch:on set sw_Light on;;sleep 60;;set sw_Light off

Manche Hardwaresysteme bieten auch den Befehl ''on-for-timer'', mit dem man alternativ schreiben kann
define n_sw_Switch_on notify sw_Switch:on set sw_Light on-for-timer 60

==Wie geht es weiter?==

Sie haben nun kennengelernt:
* Das Anlegen von FHEM-Devices mit '''define'''
* '''Events''' und den Event-Monitor
* Schalten von Devices mit '''set'''
* Verändern von Devices mit '''modify''', '''rename''' und '''delete'''
* Das Setzen und Bearbeiten von '''Attributen'''
* Event-getriebene Aktionen durch '''notify'''
* Zeitgesteuertes Schalten mit '''at'''

Damit kennen Sie die grundlegendsten Mechanismen von FHEM. Details zu diesen Befehlen finden Sie in der FHEM Befehlsreferenz {{Link2CmdRef}}.

'''Tipp:''' Zu vielen FHEM-Befehlen und Gerätetypen gibt es auch eine deutschsprachige Beschreibung. Klicken Sie dazu in der commandref oben links auf den Link "DE".

In der commandref finden Sie neben der Beschreibung aller FHEM-Befehle auch die Liste aller Gerätetypen, die in FHEM eingebunden werden können.

Sie werden feststellen, dass "echte" FHEM-Devices grundsätzlich genau so aussehen, wie die dummy-Devices, die Sie hier bereits kennengelernt haben. Der wesentliche Unterschied ist, dass Sie die verfügbaren Befehle nicht mehr selbst mittels ''attr webCmd'' festlegen müssen, da diese bereits durch das FHEM-Device vorgegeben sind. Und Events werden nicht nur ausgelöst, wenn Sie im FHEM-Webfrontend klicken, sondern auch, wenn das physische Gerät (also der Bewegungssensor oder der Lichtschalter an der Wand) auslöst.

Sobald Sie ihre ersten Geräte an FHEM gekoppelt haben, schauen Sie sich den Event-Monitor an, um zu sehen, wann welche Events ausgelöst werden.

Einen umfangreicheren Einstieg in FHEM finden Sie im Dokument [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung-mit-FHEM]

Die für FHEM wichtigen Grundlagen der Programmiersprache Perl kann man in den ersten Kapiteln eines Perl-Buches oder diversen frei im Internet verfügbaren Perl-Tutorials nachlesen.

Viel Spaß und Erfolg mit FHEM !

[[Kategorie:HOWTOS]]