Wemos D1 simple OLED display for OpenHAB

I managed to use an Wemos D1-mini and its OLED shield to create a mini-display for temperature, with (almost) no line of code.
Configuration is done once, and displayed information is entirely sent through MQTT.

Here’s a little tutorial:

  • Flash the D1 mini with Tasmota with tasmota-display.bin build
  • Perform the basic Tasmota setup (wifi, MQTT, …)
  • Connect the OLED shield on the D1 mini
  • Set the I2C pins :
    • Web interface / Configuration / Configure Module
    • D2 GPIO4 : I2C SDA
    • D1 GPIO5 : I2C SCL
  • Check the OLED shield is detected :
    22:11:45 CMD: i2cscan
    22:11:45 MQT: stat/esp01/RESULT = {"I2CScan":"Device(s) found at 0x3c"}
  • Configure the display settings through display commands :
    • DisplayModel 2 (SSD1306 ie OLED Shield)
    • DisplayWidth 64
    • DisplayHeight 48
    • DisplayMode 0
    • Optionally DisplayRotate 2 to display upside down
  • Finally, type use the Display command to check your display settings :
    {"Model":2,"Width":64,"Height":48,"Mode":0,"Dimmer":15,"Size":1,"Font":1,"Rotate":2,"Refresh":2,"Cols":[16,8],"Rows":2}}
  • Optionally “Configure timers” to turn display on/off on fixed times

The device is now ready to receive MQTT “display commands”.
I created the following rule :

rule "esp01publishtemp"
when
    Item HueSensor1Temperature received update
then
    val mqttActions = getActions("mqtt","mqtt:broker:mosquitto-nas")
    val esp01Temp = String.format("%2.1f",(newState as DecimalType).floatValue)
	logInfo("esp01.rules", "esp01publishtemp : newState=" + newState + " ,esp01Temp="+esp01Temp)
	mqttActions.publishMQTT("cmnd/esp01/displaytext","[Ozf1]Exterieur:[c1l2f2s2p-4]"+esp01Temp)
end

Explanations : When HueSensor1Temperature item is updated (no matter if it’s MQTT based or not) :

  • Format the payload with 1 decimal
  • Format the display :
    • [0zf1] : Turn the display on (0), clear it (z) and select font 1
    • Display the text for the first line (“Outside” in french here)
    • [c1l2f2s2p-4] : On column 1 (c1) and line 2 (l2), select font 2 (f2), scale factor 2 (s2) and pad 4 characters to the right (p-4)
    • Display the value
  • Send the MQTT payload to the moquitto-nas broker

At first, nothing will be displayed until the first MQTT update.

This page list all display possibilities with tasmota.

Enjoy !

Sonoff zigbee bridge with OpenHAB zigbee binding

This a copy of my post on the OpenHAB forums.

I wanted to start using zigbee at home, and I wanted it simple.

First, I bought Itead Sonoff Zigbee Bridge (SNZB or zbbridge) and flashed it with tasmota.
See https://notenoughtech.com/home-automation/flashing-tasmota-on-sonoff-zigbee-bridge or https://www.digiblur.com/2020/07/how-to-use-sonoff-zigbee-bridge-with.html (without soldering, but more HomeAssistant oriented).
It works fine, but I like items auto-discovery and don’t want to bother with magic-voodoo-json data extraction and formatting.
The article from digiblur shows native integration with HomeAssistant binding, and I’ve managed to achieve the same thing with OpenHAB.

So this is a litlle howto:

  • Read Digiblur’s article and strictly apply all steps, except the HA ones. The related video is also helpful.
    I uploaded the latest UART firmware (6.7.6), it seems you don’t have to stick to older 6.5.5 with OH
    A the end, you should be able to telnet to port 8888
  • Install socat, and bind your serial port to the zbbridge radio:
    socat -dd pty,link=/dev/ttyzbbridge,raw tcp:192.168.x.y:8888

     

    Of course, adjust the IP address to point the zbbridge one.

You can also specify owner and group with user-late and group-late to avoid permission issues :

socat -dd pty,link=/dev/ttyzbbridge,raw,user-late=openhab,group-late=dialout tcp:192.168.x.y:8888
  • Install serial binding in OH
    You must configure OH startup script to include `/dev/ttyzbbridge` as stated in the documentation
  • Install Zigbee binding in OH
  • Add a new Zigbee « Ember EM35x Coordinator » thing
    Just set the serial port to /dev/ttyzbbridge. I didn’t touch other settings since I was not sure of what they really do
  • Pair zigbee devices as stated on the zigbee binding documentation:
    Search for Zigbee things
    Put your device in pairing mode, it should appear.
    Wait for the discovery to finish (a name should appear, not « unknow zigbee device »
  • Enjoy !

I did this minutes ago, this is a basic procedure. I was able to pair Xiaomi plug, Aqara temp/hum and door sensors, and a Ikea Tradfri dimmer. Some of the devices don’t report battery status as zigbee2tasmota does.

  • There is room for a lot of enhancements, for example:
    Make socat a service with auto-reconnect
  • Fine-tune the zigbee coordinator settings

Finally, it would be great the the serial binding allows Serial-over-TCP connections as HA does with socket://<your bridge IP>:8888 as serial port path.

Lego Power Functions extension for mBlock 5

My son and I did wrote an mBlock 5 extension to control Lego Power Functions.

It is based on the Arduino library from https://github.com/jurriaan/Arduino-PowerFunctions. The whole Power Functions is not implemented, there are only 2 blocks:

  • Begin Lego Power Functions : Select the pin connected to the LED, and the receiver channel
  • Lego Power Function : Select the output (Blue or Red), and the desired action (in continuous mode)

The setup is simple : Just connect an infrared LED and a 220 ohm resistor on a digital pin (13 by default).

Sample code :

It’s being reviewed by the mBlock team and should be available soon.

Translations are welcome !

For french readers

Mon fils et moi avons créé l’extension mBlock 5 pour Lego Power Functions.

Elle est basée sur la libraire Arduino suivante : https://github.com/jurriaan/Arduino-PowerFunctions. Toutes les fonctionnalités ne sont pas implémentées, il n’y a que 2 types de blocs :

  • Démarrer Lego Power Functions :Indiquer la broche connectée à la LED infrarouge, ainsi que le canal du récepteur
  • Lego Power Function : Choisir la prise (Blue or Red) et l’action (en mode continu)

Le montage est simple, il suffit de brancher une LED infrarouge et une résistance de 220 ohms en série sur une broche (D13 par défaut).

Exemple de code :

L’extension a été soumise à l’équipe mBlock, elle devrait bientôt être publiée.

Les traductions dans d’autres langues sont les bienvenues !

Lego Boost, Scratch Link & Dongle Bluetooth CSR

Quelques notes sur ma tentative de connecter Scratch Desktop 3 à un ensemble Lego Boost…

Bluetooth 4.0 requis

Le « Move Hub » communique via BLE qui est une variante de la norme Bluetooth 4. Une puce compatible est donc requise, ce qui n’est indiqué nulle part, à part dans l’extrait d’un livre aux éditions ENI

Facile…

Mon vieux portable étant limité au Bluetooth 2.0, j’ai donc acheté un dongle USB à pas cher, basé sur un chipset CSR8510. Le mien est de marque Yizhet, il existe des modèles chez Trust, Belkin, Bluetake, Konig, … basés sur le même chipset.

Malheureusement, quand je l’ai connecté au PC, Windows 10 l’a bien reconnu, et il est apparu dans le gestionnaire de périphériques en tant que « Generic Bluetooh Radio » (IDs USB 0A12:0001) avec une erreur 10 « le périphérique n’a pas pu démarrer ».

J’insère alors le CD fourni dans le lecteur à la recherche d’un pilote, et je lance l’unique setup.exe présent sur la galette, qui procède à l’installation de « CSR Harmony Wireless Stack », qui est une pile bluetooth complète parallèle à celle de Windows 10. Avec un style Windows 7, elle semble être basée sur la suite BlueSoleil qui complétait le manque de fonctionnalité bluetooth des anciennes versions de Windows. Moche mais fonctionnelle, elle détecte bien le « Move Hub » en BLE quand je fais une recherche de périphérique.

… mais pas trop

Par contre Scratch ne détecte pas le périphérique. Scratch Link étant très peu verbeux, je n’ai pas d’explication sur ce comportement, mais je suppose qu’il se base d’abord (ou uniquement) sur la pile Bluetooth native de Windows 10.

J’essaie alors de trouver un pilote générique Windows 10 pour ce périphérique (somme toute très générique lui aussi), sans succès : Je ne trouve que des pilotes qui ont le même comportement, ou alors la suite CRS Harmony complète. CSR (Cambridge Silicon Radio) ayant été rachetée par Qualcomm en 2015, il n’y a pas d’information sur le nouveau site web.

Je tente alors diverses combinaisons avant de tomber sur une page web qui indique que Windows ne sait gérer qu’un seul récepteur Bluetooth à la fois ! Je désactive le récepteur intégré au PC (sobrement nommé « Generic Bluetooth Adapter » dans le gestionnaire de périphériques), je rebranche le dongle USB et, magie, il démarre correctement ce coup-ci.

Une recherche de périphériques Bluetooth via le panneau de configuration Windows 10 m’indique que la détection fonctionne correctement (il ne faut pas l’associer, juste vérifier qu’il apparaisse bien).

Scratch récent requis également

Autre point découvert récemment : Lego diffuse un nouveau firmware 2.x pour le Move Hub, qui casse la compatibilité avec l’ancienne API et génère un comportement incorrect.

Sur ce dernier point, il faut donc disposer de versions récentes de Scratch Desktop (3.6.0) et de Scratch Link (1.2.0), et tout rentre dans l’ordre

Le papa fiston va pouvoir commencer à jouer !

En résumé

  • Scratch Link requiert un récepteur Bluetooth 4.0 pour communiquer avec le Move Hub Lego Boost
  • Le dongle à base de chipset CSR 8510 fonctionne correctement mais
    • Il ne faut pas installer le logiciel « CSR Harmony »
    • Il faut désactiver auparavant l’éventuel périphérique Bluetooth existant
  • Il faut s’assurer d’avoir une version récente de Sratch et Sratch Link

In summary

For english readers:

  • Scratch Link requires Bluetooth 4.0 to communicate with Lego Boost Move Hub
  • CSR8510-based USB dongles works, but
    • Do not install the « CSR Harmony » software : it’s a different bluetooth stack and won’t work with Scratch Link
    • Disable any existing bluetooth receiver (through the BIOS or Windows Device Manager), or you’ll have an error « This device cannot start (code 10) »
  • Use recent versions of Scratch Desktop (3,6,0+) and Scratch Link (1.2.0+) to cope with firmware 2.x changes

Check_MK agent for Esp Easy (updated)

Here is Check_MK agent for ESP Easy.

The ESP Easy firmware can be used to turn the ESP module into an easy multifunction sensor device for Home Automation solutions like Domoticz. Configuration of the ESP Easy is entirely web based, so once you’ve got the firmware loaded, you don’t need any other tool besides a common web browser.

Quick Howto:

Download the agent package from Check_MK Exchange

  • Install the agent.
  • Create a new device in check_mk, with agent type = Check_MK Agent
  • Create a new rule « Individual program call instead of agent access » for this host and set path to
 ~/local/share/check_mk/agents/check_mk_agent.espeasy <IP>

  • Then, create your devices in ESP Easy (an Ultrasonic Sensor for example) :

  • Launch a scan, your sensors will appear, as well as device Uptime and Free RAM:

You can also monitor system values of ESP8266 (RSSI, VCC Value, …) by adding « System Info » devices on EspEasy.

Enjoy !

Update 2020/01 : This agent worked only for ESPeasy 1.x versions. The output format changed with ESPEasy 2.x. The agent version 2.0 now supports ESPEasy 2.x as well as older versions.

Duplicati package for Asustor NAS

Duplicati is an open source « backup to cloud » software, which allows to backup your data to various cloud platforms, or simply through ftp or ssh.

duplicati-screenshot

I packaged the latest version for my Asustor 3102T NAS, and submitted it for publishing through App Central. Meanwhile, you can download it from here : duplicati_1-1-1_any.apk

Update 14/11/2016: Now available in App Central, in the Beta section.

Have fun !

check-mk « check_pid »

This local check for check_mk is useful with services who won’t start if an old or incorrect pid file remains. I needed to write it because this is the very case of the postfix version embedded with zimbra.

The code is self-explanatory :

 

#!/bin/bash
# Cyril Pawelko http://www.pawelko.net/check-mk-check_pid/
# Version 1
# Checks if the PID referenced in a PIDFILE exists
# This is a "local" check_mk check for *NIX:
# - Rename it if you need several checks on the same host
# - Copy to check-mk local checks directory (/usr/lib/check_mk_agent/local on Debian)
# - Customize with the PID file path:
PIDFILE="/opt/zimbra/data/postfix/spool/pid/master.pid"

if [ ! -r $PIDFILE ]
 then echo 3 Pid_$PIDFILE - File $PIDFILE cannot be read
 exit
fi

PID=$(cat $PIDFILE  )
PID=${PID//[^0-9]/}
if ps $PID > /dev/null
 then echo 0 Pid_$PIDFILE - Process $PID referenced in $PIDFILE is running
 else echo 2 Pid_$PIDFILE - Process $PID referenced in $PIDFILE does not exist
fi

Download

Have fun !

Check_mk check for generic OID

A while ago, I wrote a simple check_mk check to monitor a single SNMP OID. I can simply be customized to quickly monitor any value, with alert levels and perfdata. Here it is :

#!/usr/bin/python
# -*- encoding: utf-8; py-indent-offset: 4 -*-

# Cyril - 28/01/2014
# Check_snmp_template for a single OID, for example .1.3.6.1.2.1.4.5.0
# How to customize :
# Break the OID in 2 parts, for instance ".1.3.6.1.2.1.4.5" and "0". Adapt baseoid and suboid.
# Adjust crit and warn values
# Replace "snmp_oid_test1" in all strings and function names
# Remplace "valeur" with a description

# OID to check
baseoid = ".1.3.6.1.4.1.6486.800.1.2.1.16.1.1.1.13"
suboid = "0"
# Warn if above this value
warn = 70
# Critical if above this value
crit = 90
# OID description (for example: CPU Utilization)
valeur = "Valeur"

def inventory_snmp_oid_test1(info):
    if len(info) > 0:
        return [ (None, (warn, crit) ) ]

def check_snmp_oid_test1(item, _no_params, info):
   value = int(info[0][0])
   perfdata = [ ("valeur", value, warn, crit) ]
   if value > crit:
           return (2, "Valeur: %i" % value, perfdata)
   elif value > warn:
           return (1, "Valeur: %i" % value, perfdata)
   else:
           return (0, "Valeur: %i" % value, perfdata)

check_info["snmp_oid_test1"] = {
        "check_function"        : check_snmp_oid_test1,
        "service_description"   : "Alcatel Switch CPU",
        "snmp_info"             : ( baseoid, [ suboid ] ),
        "has_perfdata"          : True,
        "inventory_function"    : inventory_snmp_oid_test1,
        }

# Quick and dirty scan function, testing against sysObjectID would be more efficient
snmp_scan_functions["snmp_oid_test1"] = \
        lambda oid: oid( baseoid + "." + suboid ) != None

Download it here : check_mk_generic_snmp_oid

Dell Storage Compellent SC plugin for check_mk

I wrote a check_mk check for Dell « Compellent » Storage Arrays.

It was developped for the SC4020 model, and works also for SCv2000/SCv2020 (thanks Emmanuel) and SC7020. It should work with other models (SC5020, SC8000, SC9000).

The following items can be monitored:

  • Global status, as reported by the system
  • Controllers status
  • I/O modules status
  • Disk status
  • Hardware sensors status
  • Temperatures (with performance data)
  • Power supplies status
  • Volume status
  • Servers status

sc4020_check_mk

Download from Check-MK Exchange

Have fun !

Update 27/06/2017 : Since SCOS 7.x, temperature values are not correctly reported through SNMP. This caused a crash of the temperature checks.This is a known bug which will be addressed with SCOS 7.2.10. Meanwhile, I’ll release version 1.1, containing workarounds to avoid crashes.

Agent check_mk pour Freebox Server

MAJ 08/06/2014 : Enfin packagé sous forme de fichier MKP

MAJ 25/08/2014 : Nouvelle version 1.2 : Correction d’un bug si pas de freeplug (merci à Sylvain Lemoine). Correction bug sur état des interfaces réseau.

MAJ 06/04/2015: Version 1.4 : Correction d’un bug si un le nom d’un périphérique connecté en wifi comporte un accent (merci encore Sylvain !). Meilleure remontée des traces même en mode debug.

MAJ 24/03/2016 : Version 1.5 : Meilleure gestion d’une erreur rencontrée avec une freebox neuve.

MAJ 04/11/2016 : Version 1.6 : Meilleure gestion d’une erreur rencontrée quand le dernier Freeplug est déconnecté.

MAJ 18/02/2018 : Version 1.8 : Le calcul d’uptime générait parfois des erreurs, il est désormais basé sur uptime_val, qui a été créé à ma demande.

MAJ 18/11/2020 : Version 2.1 : Passage sur l’APIv2 du wifi pour éviter une erreur sur une freebox neuve, et correction de la détection de l’état de l’interface ethernet des boitiers CPL tiers.

Le serveur de la Freebox Révolution (v6) n’est pas accessible via SNMP, ce qui rend les possibilités de supervisions bien ternes, alors que ce boitier gère en réalité de nombreuses opérations.
Courant 2013 l’API REST a été mise à jour, elle permet d’interroger de nombreux compteurs concernant la freebox.

Voici un script python qui fait office d’agent pour la solution de supervision check_mk. Pour ceux qui ne connaissent pas, c’est du Nagios sans les inconvénients de Nagios, les parties les plus rébarbatives étant remplacées par des scripts et une interface web efficaces.

Cet agent permet l’inventaire, la supervision et la création de graphiques pour les éléments suivants:

  • Freeplugs et autres équipements CPL
  • Température des processeurs, du switch et du disque
  • Vitesse du ventilateur
  • Activation du wifi
  • Connexion et force du signal des stations wifi
  • Espace libre des partitions
  • Statistiques sur les 4 interfaces du switch (état, trafic, vitesse)
  • Etat de la connexion ADSL (et peut-être VDSL)
  • Erreurs ADSL
  • Uptime

Je pense avoir intégré tout ce qui était possible.
Cependant:

  • C’est mon premier essai en python, le code n’est pas des plus sexys
  • L’état de la connexion FFTH n’a pas été implémenté
  • La gestion des erreurs sur les ports de switchs n’est pas complète

Pour l’installer, suivre la procédure suivante:

  • Installer le module « python request » (sur Debian: apt-get install python-requests)
  • Télécharger le fichier MKP ci-dessous ou sur Check MK Exchange
  • Se logger avec l’utilisateur exécutant nagios (ou l’instance d’OMD)
  • L’installer avec la commande « cmk -P install freebox-v6-1.0.mkp »
  • Repérer l’emplacement du script installé avec la commande « cmk -P list freebox-v6 »
  • Lancer le script avec l’option « -a » pour lancer la procédure d’authentification sur la freebox
  • Autoriser l’application sur l’afficheur LCD du freebox server
  • Ouvrir ensuite une session sur l’interface web du freebox server, aller dans « Paramètres / Gestion des accès / Applications » et donner le droit « Modification des réglages de la freebox » à l’application
  • Relancer manuellement le script, sans option, et vérifer que la sortie ait l’air correcte. Pour (beaucoup) plus de détails, ajouter l’option -v
  • Via WATO, ajouter un hôte Freebox avec l’IP LAN de la Freebox
  • Toujours via WATO, ajouter une règle de type « Datasource Programs / Individual program call instead of agent » pour l’hôte correspondant à la freebox
  • Indiquer le chemin complet du script, sans paramètre supplémentaire
  • Appliquer la configuration de WATO
  • Lancer un inventaire des services via WATO, sélectionner les services désirés et appliquer la configuration
  • Et hop :

nagios_freebox

Notez aussi que:

  • L’IP LAN de la Freebox n’est pas utilisée par le script (mais mafreebox.freebox.fr), mais Nagios pingera cette adresse pour vérifier l’état de l’hôte
  • Il est possible d’utiliser l’option -v pour avoir une sortie (très) détaillée ce qui se passe
  • Il est possible d’utiliser l’option -d pour logger cette sortie détaillée dans /tmp/check_mk_agent_freebox_revolution.log

Pour les curieux, cet agent utilise si possible le format standard de l’agent check_mk linux, et sinon des checks locaux.
Si vous préférez cacti, voir http://glr81.free.fr/blog/index.php?2013(..)

Reste à faire

S’il reste encore des gens motivés dans la salle, il reste à :

  • Créer des templates pnp4nagios, notamment pour l’ADSL
  • Gérer correctement les erreurs sur interfaces du switch (écrire un vrai plugin check_mk ?)
  • Compléter le package mkp, avec une page man, des perf-o-meter et tout et tout

Télécharger

Disponible sur Check_MK Exchange