Temperatur und Feuchtigkeit in Telegram vom RaspberryPI

Ich möchte hier beschreiben, wie man mit einem RaspberryPI die Temperatur und Feuchtigkeitswerte sich aufs Handy per Telegram schickt.
Verraussetzung ist ein RaspberryPI 3 b+ und ein Temperatur / Feuchtigkeitssensor, ich habe folgendes verwendet:

  • DSD TECH DHT22 AM2302 Temperatur und Luftfeuchtigkeit Sensor Modul für Arduino Raspberry Pi
  • RaspberryPI 3 B+

Anleitung wie man den Sensor an den RaspberryPI ansteckt, findet man reichlich im Netz z.B. Sensor-Einbau RaspberryPI/
Da in diesem Artikel auch schon beschrieben wird, wie man mit dem Tool Adafruit die Werte Temperatur und Feuchtigkeit ausliest, werde ich hier nicht genauer darauf eingehen.
Soviel, Ich lasse das Skript per cronjob zu bestimmten Zeiten ausführen und erhalte dann die Werte via Telegram auf mein Handy weitergeleitet.

Nur wie kann man sich die Werte auf das eigene Handy per Telegram senden lassen? Das werde ich hier kurz beschreiben.

Voraussetzung:

  • Handy mit der App Telegram (Apple IOs oder Android)

Als erstes müssen wir uns in Telegram einen eigenen Bot erstellen,  den wir später per API erreichen können,

wie das funktioniert, wird auch in vielen Webseiten bereits erklärt z.B. Telegram Bot erstellen

So, da der Bot jetzt bereit ist um per API Nachrichten zu empfangen, brauchen wir einen API-Aufruf der so aussehen kann:

curl -X POST 'https://api.telegram.org/botid:token/sendMessage?chat_id=id&text='$(/usr/local/sbin/AdafruitDHT.py 2302 4)'' > /dev/null 2>&1

Ich habe die Ausgaben die auf der Shell kommen nach /dev/null geleitet, denn die brauchen wir nicht, wenn es funktioniert.

Für die ersten Tests würde ich die Ausgabe schon sichtbar lassen, um den JSON-Output mal gesehen zu haben und gegebenenfalls Fehlermeldungen zu sehen.

curl -X POST 'https://api.telegram.org/botid:token/sendMessage?chat_id=id&text='$(/usr/local/sbin/AdafruitDHT.py 2302 4)'' | python -m json.tool

{
"ok": true,
"result": {
"chat": {
"first_name": "Johannes",
"id": 400269857,
"last_name": "Carraro",
"type": "private",
"username": "xxxx"
},
"date": 1563270619, <-- UNIXTIMESTAMP
"from": {
"first_name": "Raspberry",
"id": xxxxxx,
"is_bot": true,
"username": "xxxxx"
},
"message_id": 265,
"text": "Temp=20.8C::Humidity=75.8%"
}
}

Wie wir sehen war die Ausgabe erfolgreich und wir sollten auf dem Handy im Telegram eine neue Nachricht mit der Temperatur und Feuchtigkeit bekommen haben.

Man kann sich über den RaspberryPI mit verschiedenen Sensoren deren Werte so auf das Handy per Telegram schicken lassen, eine coole Sache.
Anwendungsbeispiel: Zimmergewächshaus, Zimmertemperatur, Außentemperatur etc.

Jetzt wünsche ich viel Erfolg beim nach basteln!

Natürlich kann ich jedem unsere Trainings nahelegen rundum OpenSource-Themen

Johannes Carraro
Johannes Carraro
Support Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Sommerhitze & Powershell 3 kleine Tipps

Hallo Netways Follower,

Ich melde mich dies mal mit einem kurzen aber meist vergessenen Thema nämlich wie kriegt man unter Windows diese vermaledeiten Powershell Skripts korrekt zum laufen.

Wenn man bei einem normalen Icinga2 Windows Agenten diese in ‘Betrieb’ nehmen will benötigt es etwas Handarbeit und Schweiß bei diesen Sommertagen um dies zu bewerkstelligen.

Trotzdem hier ein paar Tipps:

1) Tipp “Powershell Skripte sollten ausführbar sein”

Nachdem der Windows Agent installiert und funktional ist sollte man sich auf der Windows Maschine wo man das Powershell Skript ausführen möchte in die Powershell (nicht vergessen mit Administrativer Berechtigung) begeben.

Um Powershell Skripts ausführen zu können muss dies erst aktiviert werden dazu gibt es das folgende Kommando

Set-ExecutionPolicy Unrestricted
Set-ExecutionPolicy RemoteSigned
Set-ExecutionPolicy Restricted

Hier sollte zumeist RemoteSigned ausreichend sein, aber es kommt wie immer auf den Anwendungsfall an. More Info here.

Nach der Aktivierung kann man nun überprüfen ob man Powershell Skripts ausführen kann.
Hierzu verwende ich meist das Notepad um folgendes zu schreiben um anschließend zu prüfen ob das oben aktivierte auch klappt.

Also ein leeres Windows Notepad mit dem folgenden befüllen:

Write-Host "Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul. "

Das ganze dann als ‘test.ps1’ speichern.

Nun wieder in die Powershell zurück und an dem Platz wo man das Powershell Skript gespeichert hat es mit dem folgenden Kommando aufrufen.
PS C:\Users\dave\Desktop> & .\test.ps1
Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

Sollte als Ergebnis angezeigt werden damit Powershell Skripts ausführbar sind.

2) Tipp “Das Icinga2 Agent Plugin Verzeichnis”

In der Windows Version unseres Icinga2 Agents ist das standard Plugin Verzeichnis folgendes:
PS C:\Program Files\ICINGA2\sbin>

Hier liegen auch die Windows Check Executables.. und ‘.ps1’ Skripte welche auf dem Host ausgeführt werden sollten/müssen auch hier liegen.

3) Tipp “Powershell 32Bit & 64Bit”

Wenn ein Skript relevante 64Bit Sachen erledigen muss kann auch die 64er Version explizit verwendet werden in den Check aufrufen.

Das heißt wenn man den object CheckCommand “Mein Toller Check” definiert kann man in dem Setting:

command = [ "C:\\Windows\\sysnative\\WindowsPowerShell\\v1.0\\powershell.exe" ] //als 64 Bit angeben und
command = [ "C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe" ] // als 32Bit.

Hoffe die drei kleinen Tipps erleichtern das Windows Monitoring mit Powershell Skripts.
Wenn hierzu noch Fragen aufkommen kann ich unser Community Forum empfehlen und den ‘kleinen’ Guide von unserem Kollegen Michael. Icinga Community Forums

Ich sag Ciao bis zum nächsten Mal.

David Okon
David Okon
Senior Consultant

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Terraform Changes

Hallo!

Was vielen von unseren Lesern entgeht, ist das wir auch in unserem Alltag zwischen der ganzen Softwareschreiber- und Kompilier- Tätigkeiten auch ganz viele virtuelle Maschinen und Container zum testen selbiger Software rauf und runter installieren müssen, und das Tag für Tag.

Deshalb versuchen wir uns das Leben mit dafür erstellter Software und deren arbeitserleichternden Funktionen leichter zu machen. Wie mein Kollege schon in seinem Blogpost im März mir vorgegriffen hat, benutzen wir bei der Netways Terraform. Achim wird in weiteren Artikeln darauf eingehen wie man Openstack per Terraform nach seiner Pfeife tanzen lassen kann und Ich möchte mich heute auf ein anderes Terraform Thema beziehen, nämlich dem nahen Release von Terraform 0.12.

Zu dem Zeitpunkt wo ich diese Zeilen niederschreibe, ist auf der aktuellen Website von Hashicorp noch die Aktuelle Version 0.11.13 zu finden.

Aber Terraform hat uns schon vielversprechendes gezeigt mit dem 0.12.0-beta1 pre-release.

Damit kann man schon die vielen Erleichterungen, welche der neue Terraform Release mit sich bringt erahnen und auch schon antesten. Ich versuche die Änderungen Anhand eines kleinen Beispiels zu erläutern.
Vielleicht kann ich den einen oder anderen IaaS Codeschreiber, welcher sich hierfür interessiert, etwas auf den Geschmack zu bringen schon etwas zu testen mit der neuen Version.

Hier der Unterschied zwischen einer (aktuell 0.11.13) alten Terraform Version und einer neuen Version in Terraform 0.12 durch eine Gegenüberstellung.

main.tf (Random Tiernamen Beispiel)

variable "count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "zoo_enabled" { default = "0" } variable "prefix_liste" { default = [] } resource "random_pet" "my_pet" { count = "${var.count}" prefix = "${var.zoo_enabled == "0" ? var.default_prefix : element(concat(var.prefix_liste, list (""), count.index)}" }

main.tf HCL2 Version(Random Tiernamen Beispiel)

variable "pet_count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "prefix_list" { default = [] } resource "random_pet" "my_pet" { count = var.pet_count prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix }

Die Unterschiede fallen zuerst etwas weniger ins Auge, sind aber dafür meines Erachtens tiefgreifender für Leute, die IaaS Code schreiben müssen und dienen der Lesbarkeit des Codes.

Vorteil Nummer 1:
Im alten Beispiel musste noch mit “${var.count}” von einem String zu einer Number evaluiert werden. Mit der neuen HCL2 Schreibweise entfällt das, und es kann mit var.pet_count direkt der korrekte String oder Number Wert adressiert werden.

Vorteil Nummer 2:
Auch die Evaluierung der Liste prefix = “${var.zoo_enabled == “0” ? var.default_prefix : element(concat(var.prefix_liste, list (“”), count.index)}”  wird mit der neuen Notation der HCL2 wesentlich eingängiger. prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix ist prägnanter. Es entfällt auch die element(concat(x), list(“”), x ) Hack-Situation, um aus einer leeren Liste auch eine Liste mit einem NULL Element zum machen.

Weitere Vorteile: es gibt viel mehr was geändert worden ist, if you want to know more, klick here.

Ich hoffe ich habe euch nicht zu sehr gelangweilt mit C.O.D.E. kurz vor dem Wochenende.

Gruß David

 

David Okon
David Okon
Senior Consultant

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...
FM Empfänger mit dem Raspberry Pi 3

FM Empfänger mit dem Raspberry Pi 3

Es gibt viele Projekte für Einsteiger, um mit einem Raspberry Pi kleineres zu realisieren. Unter anderem ein FM Empfänger, wofür die folgende Anleitung genutzt werden kann.

Materialien: 

  1. Raspberry Pi 3
  2. Female Female Jumper
  3. Tea5767 Modul
  4. Lautsprecher (Beispiel)
  5. AUX Kabel

Vorgehen: 

1) Die mitgelieferte SD Karte enthält bereits ein Noob OS, womit Raspian installiert werden kann. Sollte ein anderes Kit ohne Karte bestellt werden, braucht man natürlich auch eine SD Karte. Noob OS dann einfach herunterladen, entpacken und auf die Karte kopieren

2) I2C aktivieren via: sudo raspi-config
-> Interfacing Options
-> I2C
-> YES

3) Der Raspberry Pi muss natürlich auch mit dem Modul verbunden werden. Hierzu werden die Female-Female Jumper benutzt.
Raspberry Pi    Tea5767
5V              5V
SDA.1           SDA
SCL.1           SCL
GND             GND

Auf welche Pins nun genau gesteckt werden muss, kann mittels gpio readall herausgefunden werden. Falls SDA.1 und SCL.1 bereits in Verwendung sind, kann auch auf 0 oder 2 ausgewichen werden.

4) Ob das Modul auch erkannt wurde, wird folgendermaßen überprüft:
i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Die “1” steht hier für SCl.1 und SDA.1 – sollte SDA.0 und SCL.0 verwendet worden sein, muss der Command entsprechend angepasst werden.  Wenn in der angezeigten Tabelle keine Zahl erscheint, wird das Modul nicht erkannt. Dies liegt meist an einer falschen Verkabelung oder einem defekten Modul.

5) Aus einer anderen Anleitung haben wir uns eines Links zum Code bedient, das den Tea5767 steuert. Es kann hier natürlich selbst auch ein Skript geschrieben werden, wenn tiefere Einblicke gewünscht sind. Hierfür wird python3 benötigt sowie verschiedene Module. Beim ersten Aufruf des Skriptes wird aber mitgeteilt, ob etwas nachinstalliert werden muss, oder nicht. Falls das der Fall ist, kann mit pip3 install $modul entsprechend nachjustiert werden.
Unter /home/pi ein neues Verzeichnis (z.B.: PiFM) erstellen und das Skript dort ablegen.

6) Mit python3 radio.py kann nun der eigentliche Radio gestartet werden. Es empfiehlt sich, das Skript kurz durchzulesen, da der Radio über Tasten gesteuert wird. So wird mit “W” die Frequenz um +1 verändert, mit “E” um +0.1

Alles in allem ist das ein schönes Projekt um erste Eindrücke in die Funktionsweise eines Raspberry Pis zu bekommen und wie bestimmte Module funktionieren, verbunden und genutzt werden. Interessant wird das auch, wenn man parallel dazu mit einem 2. Pi einen FM Transmitter aufbaut. Hierzu gibt es in einem späteren Blogpost aber mehr.

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile

This entry is part 9 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Es ist nun nahzu schon ein Jahr her, dass in dieser Blogserie ein Artikel erschien. Zeit diese Serie fortzusetzen, auch weil wir für diese Jahr noch den Release 2.0.0 des Moduls puppet-icinga2 planen. In den kommenden Artikeln möchte ich sukezessive eine Profil-Klasse entwickeln, die einen Icinga-2-Server inklusive Plugins, IDO, Api und Icinga Web 2 installiert und konfiguriert. Als weitere Anforderung soll dies erfolgreich auf RedHat- wie auch Debian-Systemen durchgeführt werden können. Getestet wurde der Code auf Debian-9 (stretch) und CentOS-7.
Als erstes Teilziel für diesen Artikel soll Icinga 2 nebst Plugins enthalten sein. Bei den Plugins soll auch berücksichtig sein, dass es Plugins wie check_icmp oder check_dhcp gibt, die erweiterte Berechtigungen benötigen. So dürfen ICMP-Pakete oder auch DHCP-Request auf Unix nur im Ring-0 erzeugt werden. Auf RedHat wird dies über das Setzen des setuid-Bits erreicht, unter Debian mittels Posix Capabilities. Damit stellt uns Debian nicht vor größere Herausforderungen, die Plugins für RedHat-Systeme erfordern jedoch, dass der Aufrufende Benutzer Mitglied der Gruppe nagios sein muss. Um dies Anforderung zu realisieren, muss der Benutzer icinga der Gruppe nagios hinzugefügt werden, dass bei Puppet heißt, er ist via User-Resource zu verwalten. Am besten überlässt man das Anlegen vom Benutzer icinga weiterhin dem Paket icinga2, damit werden solche Eigenschaften wie UID oder das Home-Verzeichnis dem Paketverantwortlichen überlassen, d.h. aber auch die Paketinstallation muss vor der User-Resource und die wiederum vor der Klasse icinga2 abgearbeitet werden. Der Service, der von der Klasse verwaltet wird, darf erst gestartet werden, wenn der Benutzer schon korrekt konfiguriert ist. Andernfalls würde Icinga als Prozess weiterhin unter einem Benutzer laufen, der zum Startzeitpunkt von seiner Zugehörigkeit zur Gruppe nagios noch nichts wusste.
Zusätzlich muss auch die Gruppe nagios vor der User-Resource vorhanden sein, was sichergestellt ist, wenn vorher das Paket nagios-plugins-all installiert ist.

class profile::icinga2::server {
  case $::osfamily {
    'redhat': {
      require ::profile::repo::epel
      require ::profile::repo::icinga
      $manage_package = false
      $manage_repo    = false
      package { [ 'nagios-plugins-all', 'icinga2' ]:
        ensure => installed,
        before => User['icinga'],
      }
      user { 'icinga':
        groups => [ 'nagios' ],
        before => Class['icinga2']
      }
    } # RedHat
    'debian': {
      $manage_package = true
      $manage_repo    = true
      package { 'monitoring-plugins':
        ensure => installed,
      }
    } # Debian
    default: {
      fail("'Your operatingsystem ${::operatingsystem} is not supported.'")
    }
  } # case
  class { '::icinga2':
    manage_package => $manage_package,
    manage_repo    => $manage_repo,
  }
}

Die Plugins befinden sich bei RedHat in einem zusätzlichen Repository, dem EPEL-Repository, das in der dedizierten Profilklasse profile::repo::epel verwaltet wird. Gleiches gilt für das Icinga-Repo mit der Klasse profile::repo::icinga, was auf RedHat für die gesonderte Paketinstalltion vorhanden sein muss und damit nicht, wie unter Debian, der Klasse icinga2 überlassen werden kann.

class profile::repo::epel {
  yumrepo { 'epel':
    descr => "Extra Packages for Enterprise Linux ${::operatingsystemmajrelease} - \$basearch",
    mirrorlist => "https://mirrors.fedoraproject.org/metalink?repo=epel-${::operatingsystemmajrelease}&arch=\$basearch",
    failovermethod => 'priority',
    enabled => '1',
    gpgcheck => '1',
    gpgkey => "http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-${::operatingsystemmajrelease}",
  }
}
class profile::repo::icinga {
  yumrepo { 'ICINGA-release':
    descr => 'ICINGA (stable release for epel)',
    baseurl => 'http://packages.icinga.org/epel/$releasever/release/',
    failovermethod => 'priority',
    enabled => '1',
    gpgcheck => '1',
    gpgkey => 'http://packages.icinga.org/icinga.key',
  }
}
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Multiplatform multimeaning multiprotocol desktop messenger – Franz

Gunnar hatte es hier schon einmal kurz angerissen, ich möchte heute nochmal verstärkt darauf zeigen:
Die Application “Franz” auf dem Desktop.
Mit Franz ist hier nicht nur ein ehemaliger Kaiser Österreichs gemeint, sondern eine Multimessengerapp. Diese unterstützt nicht nur unterschiedliche Messenger wie WhatsApp, Slack usw. sondern läuft auch auf Windows, Mac und Linux.
In den Funktionalitäten konnte ich keine Unterschiede zwischen den “nativen” Clients und Franz feststellen.

mmehrere Mmessenger, eine Oberfläche


Das Programm kommt aus Wien und der Datenschutz wird somit auch europäisch reguliert – also gerne ausprobieren!

Tim Albert
Tim Albert
System Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...