Planungsfrage:Raspberry, FHEM, KEIN Funk, DS1820

[Thomas_SH]

Hallo,

ich bin neu hier und habe schon viel gelesen, teilweise widersprüchliches. Darum fasse ich meine Hardware und meine Ideen mal zusammen und dann kommen die Fragen.

Raspberry Pi 2B, DS1820 Temperatursensoren, Fritzbox 6390, Mac Mini.

Ich möchte demnächst (Sommer / Herbst) den 20 Jahre alten Gasofen austauschen. Neben dem Ofen gibt es eine Wärmepumpe, die aus der reichlich vorhandenen Abwärme des Ofens das Warmwasser aufheizt. Außerdem habe ich ein sogenanntes "Kaltdach", d.h. das Dach selbst ist NICHT isoliert, sondern die Geschoßdecke. Es liegen also nur die nackten Pfannen und eine Plasitkfolie auf den Dachsparren.

Und genau hier ist der erste Ansatzpunkt: Das Dachgeschoß (höchste Höhe: ca. 3,20 Meter, ca. 100qm Grundfläche) ist selbst bei mäßigen Temperaturen (Ende April, Anfang Mai: Aussen 10-13 Grad C) schon recht mollig warm. Jetzt im Augenblick: Trocken, 60% Wolken (geschätzt), 13,5 Grad aussen, Meßwerte nach DS1820

Gemessene Temperatur des Sensors 1 (Dach):  18.12 °C (3 Meter)
Gemessene Temperatur des Sensors 3 (Dach):  17.12 °C  (2 Meter)
Gemessene Temperatur des Sensors 2 (Thomas):  22.62 °C (Arbeitszimmer)

Die Sensoren auf dem Dach lese ich derzeit noch von Hand aus, das soll automatisiert werden, um eine Einschätzung zu bekommen, ob das Dach als Wärmequelle für die Wärmepumpe nutzbar ist. Das soll automatisiert, angezeigt (Mac OS Desktop) und in eine Tabelle (txt oder odt-Datei) geschrieben werden (incl. Datum, Uhrzeit, min 3 Meßstellen, max. 30).

Laut div. Forenbeiträgen kann der Pi ohne Kernelpatch nur 10 Sensoren auslesen. Und er soll angeblich auch nur am GPIO4 die Funktionalität "1-wire" haben. In einigen wenigen Beiträgen steht aber, das der Kernel auf eine beliebige Anzahl gepatcht werden kann und das auch andere GPIOs genutzt werden können. Weiss jemand von den Mitlesern, ob die Begrenzung auf 10 Sensoren pro GPIO bezogen ist oder auch gilt, wenn ich an 2 GPIOs je 5 Sensoren ranhänge?

Jedenfalls möchte ich vermeiden, bei jeder BS-Update-Geschichte wieder den Kernel selbst anpassen zu müssen. Gibt es da einen Automatismus?

Dann die Kabellänge von 1-wire. Da steht in div. Beiträgen, am besten ist ein langes Kabel mit kurzen Abzweigen. Wenn ich meine über 30 Sensoren ab so anschließen würde, dann ich locker auf über 150 Meter Kabellänge kommen. Ich habe 4-adriges Kabel (Telefonleitung), also mache ich gerne eine 3-adrige Verkabelung. Aber kann der Pi (und danach FHEM) auch mit 3, 4 oder 5 Kabeln an je einem GPIO zurechtkommen um die 30 Sensoren auszulesen?

Außerdem habe ich die Starteranleitung zu FHEM überflogen. Es wird fast nur auf Funkver"kabelung" eingegangen. Ich möchte jedoch möglichst kein Funk im Haus haben, sondern alles über Kabel lösen. (Es reicht schon, das 2 Telefone und 2 Tabletts ein WLAN benötigen)

Wie bekomme ich jetzt die DS1820 per Kabel in das FHEM-Paket eingelesen, so das die Auswertung einmal per WEB-GUI erfolgt (am Mac) und einmal per Datei (wie oben beschrieben)?

Und noch eine Frage: Die Sensoren legen im pi-Dateisystem Ordner mit ihren Hardwareadresse als Dateinamen an. An sich eine schöne Sache. Aber funktioniert die Auswertung auch, wenn ich Alias(e) anlege? Da wäre es einfacher "Dach3m" zu erkennen als "28-000006377a15"...
Thomas

[Muschelpuster]

Hallo Thomas,

Ich stehe auch gerade am Anfang, kann Dir aber vielleicht etwas helfen, weil ich ähnliche Sorgen habe.



• Ich habe arbeite nicht am GPIO, sondern habe mir das 1-Wire-Modul von Sheepwalk-Electronic gegönnt. Das hebt die Einschränkungen auf, nur die Stromversorgung des PI muss ausreichen, was bei dem Verbrauch von DS1820 wohl eher nicht das Problem ist. Im Wiki sind alle Möglichkeiten der Umsetzung mit einem RaspberryPi beschrieben: http://www.fhemwiki.de/wiki/Raspberry_Pi_und_1-Wire
• Ein Alias ist nur ein Alias, der hat keine Auswirkung auf die Auswertung. Man kann allerdings auch den Sensor umbenennen (wenn man es richtig macht): http://forum.fhem.de/index.php/topic,37184.msg295087.html
  Das ist IMHO eine praktikable Geschichte, denn wenn Du die Daten aufzeichnen willst, musst Du in der Log-Definition auf den Sensornamen und nicht den Alias matchen. Bei bunt gewürfelten Namen wird das schnell unübersichtlich.
• Telefonkabel ist nicht gleich Telefonkabel. Es gibt IY(St)Y 2x2 und es gibt IYY 2x2. Das St bedeutet, dass das Kabel geschirmt ist. Hier hätte ich wenig Bedenken. Wobei Du ja keine Sterntopologie aufbauen musst. Ich würde +/- sternförmig schalten und die Daten als Hin-& Rückleitung aufbauen. Also z.B. Rot & Schwarz für die Stromversorgung, Weiß die Hinleitung im Stich und Gelb die Rückleitung. Dann am Verteilerpunkt die gelbe Ader wieder auf die Weiße der nächsten Stichleitung schalten. Wobei Du dann sicher auch über die 150m maximal empfohlene Länge kommst (http://shop.wiregate.de/1-wire-bus). Wikipedia sieht jedoch sogar theoretisch 300m als möglich an (http://de.wikipedia.org/wiki/1-Wire#Leitungsanforderungen).
  Alternativ gibt es ja auch noch 1-Wire-Hubs...
• Von Hause aus kann man in eine Datei loggen und idiese direkt auf der FHEM-Seite visualisieren. Alternativ ist es jedoch auch möglich, in eine DB zu schreiben - eines meiner mittelfristigen Ziele..

So sieht derzeit die Konfiguration meiner Sensoren aus (Auschnitt):

Code Auswählen Erweitern

define 1Wire_TerraTemp_RU OWDevice 10.8653B3020800 240
attr 1Wire_TerraTemp_RU IODev localOWServer
attr 1Wire_TerraTemp_RU alias E.T. rechts unten
attr 1Wire_TerraTemp_RU model DS18S20
attr 1Wire_TerraTemp_RU room Terrarium,all

define 1Wire_TerraTemp_RO OWDevice 10.564FB3020800 240
attr 1Wire_TerraTemp_RO IODev localOWServer
attr 1Wire_TerraTemp_RO alias E.T. rechts oben
attr 1Wire_TerraTemp_RO model DS18S20
attr 1Wire_TerraTemp_RO room Terrarium,all

define 1Wire_TerraTemp_MU OWDevice 10.9732B3020800 240
attr 1Wire_TerraTemp_MU IODev localOWServer
attr 1Wire_TerraTemp_MU alias E.T. Mitte unten
attr 1Wire_TerraTemp_MU model DS18S20
attr 1Wire_TerraTemp_MU room Terrarium,all

Durch den gemeinsamen Namenspräfix 1Wire_TerraTemp kann ich alle Daten mit einem kleinen regulären Ausdruck in ein Log schieben:

Code Auswählen Erweitern

define FileLog_Terrarium FileLog ./log/Terrarium-%Y-%m.log 1Wire_TerraTemp.*temperature.*
attr FileLog_Terrarium icon icoLog
attr FileLog_Terrarium nrarchive 12
attr FileLog_Terrarium room Logfiles


Abschließend wird ein Plot gebaut (passt jetzt nicht ganz, weil ich auch noch einen Luftfeuchtesensor habe):

Code Auswählen Erweitern

define Terrarium_1 SVG FileLog_Terrarium:Terrarium_1:CURRENT
attr Terrarium_1 room Terrarium
attr Terrarium_1 title "Luftfeuchtigkeit  (Min $data{min1}%, Max $data{max1}%, Aktuell $data{currval1}%)"

Nachdem man das Plot konfiguriert hat, könnte es so aussehen, wie im Anhang.

ansatzweise Grüße
Niels

[Thomas_SH]

Danke für die ausführliche Antwort.

[Prof. Dr. Peter Henning]

Erst einmal halte ich es für unwahr, dass man hier im Forum "Widersprüchliches" liest.

Zweitens verweise ich auf http://www.fhemwiki.de/wiki/1-Wire_Busverlegung.

Drittens rate ich ausdrücklich davon ab, den 1-Wire Bus direkt über GPIO auszulesen. Man leiste sich bitte für 20 € einen anständigen Busmaster.

LG

pah

[Thomas_SH]

Erst einmal halte ich es für unwahr, dass man hier im Forum "Widersprüchliches" liest.

Nicht in FHEM, sondern im gesamtem Internet.

Zweitens verweise ich auf http://www.fhemwiki.de/wiki/1-Wire_Busverlegung.

Da steht nichts interessantes drin. E-Grundlagen halt. Hatte ich vor 35 Jahren in der Berufsschule.

Drittens rate ich ausdrücklich davon ab, den 1-Wire Bus direkt über GPIO auszulesen. Man leiste sich bitte für 20 € einen anständigen Busmaster.

LG

pah

Warum nicht über GPIO? Warum zusätzliches Geld für einen Busmaster ausgeben, wenn der Pi die Funktion schon hat? (Wenn möglich bitte auf Ebene eines Elektronikers antworten)

Thomas

[Prof. Dr. Peter Henning]

Ach, erst die vorhandenen Dokumentationen als uninteressant abqualifizieren, aber dann eine zielgruppenspezifische Antwort verlangen ? Angenehmes Träumen wünsche ich.

pah

[pula]

@pah: Da ich grade auch in der Planungsphase bin: warum ist ein eigener Busmaster so empfehlenswert bzw. gilt die Emppfehlung nur für die GPIO des Raspberry oder auch für Arduino (der diese Funktionalität ja auch mitbringt).
Eine Antwort würde mir (und wahrscheinlich auch vielen anderen Anfängern) hier weiterhelfen.

Zu der Dokumentation möchte ich sagen: Es stehen zweifelsohne sehr viele wichtige und gute Informationen drin, aber zumindest _ich_ konnte daraus nicht lesen, wie am besten vorzugehen ist.
Da ich eher kein Elektriker bin, interessieren mich aber wahrscheinlich auch viele Basics, die andere als trivial einschätzen (zb: wie genau sollten Abzweigungen am besten umgesetzt werden - Stecksystem, Klemmen etc).

Ich habe mir vorgenommen, daß ich hier (im WIKI) ein wenig ergänzen werde, sobald ich mein Projekt umgestzt und ein paar eigene Erfahrungen gemacht habe, weil ich auch hier vermute, daß ich nicht der Einzige bin, dem es so geht, daß er vor einer Wand steht und nicht weiß, wo er zu suchen beginnen soll.....

Pula

[ritchie]

Hallo Pula,

ganz kurz erläutert.

1-wire-Komponenten können direkt an den GPIO-Port des RPi angeschlossen und in FHEM konfiguriert werden

bei der Verwendung der GPIO Lösung (verwende ich selber nicht), wird ein direkter PIN eines PORT-Baustein RPi verwendet.
Das Timing des Bus wird durch die Software des RPI (1-wire Driver) realisiert.
(Ansteuerung des High/Low Signals für jedes 1-wire Signals)

Die Verwendung eines USB Busmasters verwendet einen speziellen Baustein von Dallas/Maxim, welcher die gesamte Datenübertragung eigenständig steuert. Hierbei wird das Timing durch diesen Baustein durchgeführt, was
a) die CPU entlastet, da er nur die zu sendenden Daten zur Verfügung gestellt bekommt und den Rest selber macht
    also das Byte auf den Bus mit den entsprechenden Steuersignalen legt.
b) die vorgeschriebene Spezifikation des 1-wire Protokolls mit Sicherheit einhält.

Gruss R.

[pula]

Hallo!

@ritchie: aahhhh.... danke für die Erläuterung!
Habe folgende Situation:
fhem im Keller auf Fedora (IBM x3650)
Weg in die Wohnung ca. 30 m
Also wäre wahrscheinlich die beste Lösung für 1wire, einen Raspi (den ich noch rumliegen habe) per fhem2fhem mit einem USB-Busmaster einzubinden?

Cheers,

Pula

[Prof. Dr. Peter Henning]

Kann man machen - verschwendet aber Energie.

Einfachere Lösung: Entfernten 1-Wire Bus direkt via WLAN anbinden. http://www.fhemwiki.de/wiki/1W-IF-WIFI

LG

pah

Außerdem ist noch zu beachten, dass bei komplexen 1-Wire Installationen die Adressierung der Devices auf dem Bus ziemlich zeitintensiv ist. Die wird von einem ordentlichen Busmaster weitgehend selbst erledigt und muss bei softwareseitigen Emulationen von der CPU eben in Echtzeit durchgezogen werden.

[Thomas_SH]

...

Die Verwendung eines USB Busmasters verwendet einen speziellen Baustein von Dallas/Maxim, welcher die gesamte Datenübertragung eigenständig steuert. Hierbei wird das Timing durch diesen Baustein durchgeführt, was
a) die CPU entlastet, da er nur die zu sendenden Daten zur Verfügung gestellt bekommt und den Rest selber macht
    also das Byte auf den Bus mit den entsprechenden Steuersignalen legt.
b) die vorgeschriebene Spezifikation des 1-wire Protokolls mit Sicherheit einhält.

Um wieviel (% oder was auch immer) belastet die "Eigenverarbeitung" eines Pi die CPU gegenüber der externen Busmaster-Version? Denn der muß auch abgefragt werden..

Nur so nebenbei: Ich habe in einem anderem Forum gefunden, wie auch 20 oder 30 DS18B20 am Pi ohne externen Busmaster laufen. 24 habe ich jetzt an meiner Fußbodenheizungsverteilerstation (12 Heizkriese) plus 3 als Raumsensoren. Funktioniert prima. Und die CPU-Last in der Pi-eigenem Auslastungsanzeige ist nicht merkbar angestiegen.

Thomas

[Prof. Dr. Peter Henning]

Unsinn. 

Es geht nicht um die CPU-Last, sondern um das Timing. Linux auf einem Raspberry Pi ist kein Echtzeit-Betriebssystem. Es ist also keineswegs gewährleistet, dass bei einer komplexen 1-Wire Installation, die über ein paar triviale Temperatursensoren hinausgeht, die strikten Timing-Vorgaben eines 1-Wire Suchalgorithmus durch die CPU eingehalten werden können.

Aber bitte: Wer es besser weiß, soll eben mit seinen eigenen Lösungen glücklich werden, wir leben schließlich in einer freien Welt.

pah

[ritchie]

Hallo,

Code Auswählen Erweitern

Aber bitte: Wer es besser weiß, soll eben mit seinen eigenen Lösungen glücklich werden, wir leben schließlich in einer freien Welt.
Sehe ich genauso.

Wir reden hier von 20-30 Euro.  . Das ist genau der falsche Punkt um zu sparen !

[Thorsten Pferdekaemper]

Hi,
ich moechte hier mal wieder auf die HBW-Geraete (Homematic-Wired-Homebrew) verweisen: http://www.fhemwiki.de/wiki/HBW-1W-T10. Das funktioniert ganz ohne Funk und der RasPi braucht nur einen einfachen RS485-USB-Stick.
Die HMW-Integration in FHEM ist inzwischen auch ziemlich fortgeschritten.
Gruss,
   Thorsten

[Thomas_SH]

Erst einmal halte ich es für unwahr, dass man hier im Forum "Widersprüchliches" liest.

Zweitens verweise ich auf http://www.fhemwiki.de/wiki/1-Wire_Busverlegung.

Drittens rate ich ausdrücklich davon ab, den 1-Wire Bus direkt über GPIO auszulesen. Man leiste sich bitte für 20 € einen anständigen Busmaster.

Hallo,

ich nochmal. Ich bin inzwischen einige Schritte weiter, auch ohne Hilfe aus diesem Forum. Und ich bin gerne bereit, meine Erkentnisse zu teilen:

Am GPIO des Pi hängen inzwischen 28 (!) Sensoren. Weitere werden folgen. Die Sensoren benötigen aufgrund der Menge einen anderen Widerstandswert, ich habe der Einfachheit halber gleich ein Poti eingelötet. Den genauen Wert werde ich in den nächsten Tagen nachreichen.

Der Pi ist, wenn die Messung erfolgt, zu wahnsinnigen 4% ausgelastet (laut grafischer Anzeige auf dem Monitor). Da er sonst bei 0% rumlangweilt "belasten" die 28 Sensoren den Pi also nicht wirklich.

Um eine weitere Einschätzung bezüglich meiner Wärmepumpe vorzunehmen werden im Moment erst einmal alle 5 Minuten automatisch alle Werte ausgelesen und in eine Datei geschrieben. Ja, diese Datei wächst schnell (um 1,2kilobyte alle 5 Minuten) aber bei 25 Gigabyte freiem Speicher auf der SD-Karte sollte das für den Sommer ausreichen...

Falls die automatische Auswertung interessant ist hänge ich noch mal das Python-Progrämmchen unten dran. Das interessante daran ist der letzte Block (ab "print temperature"), der Rest ist überwiegend aus dem Netz gefischt.

Thomas

Code Auswählen Erweitern

#!/usr/bin/env python
# -*- coding: utf-8 -*-

#
# Creation:    02.01.2013
# Last Update: 07.04.2015
#
# Copyright (c) 2013-2015 by Georg Kainzbauer <http://www.gtkdb.de>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#

# import sys module
import sys
import time


# open 1-wire slaves list for reading
file = open('/sys/devices/w1_bus_master1/w1_master_slaves')

# read 1-wire slaves list
w1_slaves = file.readlines()

# close 1-wire slaves list
file.close()

# print header for results table
now = time.localtime()
print(time.strftime("%d.%m.%Y %H.%M"))

print("Sensor ID       | Temperatur")
print("-----------------------------")

# repeat following steps with each 1-wire slave
for line in w1_slaves:
 
  # extract 1-wire slave
  w1_slave = line.split("\n")[0]

  # open 1-wire slave file
  file = open('/sys/bus/w1/devices/' + str(w1_slave) + '/w1_slave')

  # read content from 1-wire slave file
  filecontent = file.read()

  # close 1-wire slave file
  file.close()

  # extract temperature string
  stringvalue = filecontent.split("\n")[1].split(" ")[9]

  # convert temperature value
  temperature = float(stringvalue[2:]) / 1000

  # print temperature
  fd=open('Messwerte.txt', "a")
  print(str(w1_slave) + " | %5.1f °C" % temperature)
  fd.write(time.strftime("%d.%m.%Y %H.%M") +"; "+ str(w1_slave) + " ; %5.1f °C" % temperature)
  fd.write('\n')
  fd.close

# quit python script
sys.exit(0)