Dashboard d’énergie sous Home Assistant avec coûts journaliers

Cet article présente la configuration de senseurs de type « pince » (dans le cas présent: via une gateway envoy d’Enphase) afin de calculer:

  • La production journalière
  • La consommation (import et/ou solaire) journalière
  • L’exportation journalière d’énergie (production solaire)

Cette configuration se faisant de manière relativement simple sous Home Assistant, je voulais également calculer le coût quotidien de l’électricité.

Enphase propose déjà la gestion de tarif sur enlighten (leur portail online) mais je voulais avoir la même chose sur Home Assistant afin de ne pas dépendre d’Enphase pour stocker et consulter ces données.

Cet article traite le cas où les pinces sont branchées en consommation et en production. Il faut donc calculer la puissance produite et consommer. A cet effet, il faut déclarer deux senseurs dans configuration.yaml :


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
template:
  - sensor:
        name: Grid Import Power
        state_class: measurement
        icon: mdi:transmission-tower
        unit_of_measurement: W
        state: >
            {{ [0, states('sensor.envoy_<id>_current_power_consumption') | int(0) - states('sensor.envoy_<id>_current_power_production') | int(0) ] | max }}
  - sensor:
        name: Grid Export Power
        state_class: measurement
        icon: mdi:transmission-tower
        unit_of_measurement: W
        state: >
            {{ [0, states('sensor.envoy_<id>_current_power_production') | int(0) - states('sensor.envoy_<id>_current_power_consumption') | int(0) ] | max }}

Nous allons également déclarer un senseur pour le tarif heure pleine / heure creuse de la Romande Energie.


1
2
3
4
5
6
7
8
9
10
11
  - sensor:
        name: Tariff Price
        unit_of_measurement: CHF/kWh
        state: >
            {% if is_state('select.energy_meter_tarif', 'hp') %}
                {{ 0.3675}}
            {% elif is_state('select.energy_meter_tarif', 'hc') %}
                {{ 0.2323}}
            {% else %}
                {{ 0 }}
            {% endif %}

Il s’agit du tarif horaire, ne comprenant pas la taxe d’abonnement de 9CHF / mois mais comprenant : Electricité + acheminement + taxe Swissgrid+ Taxe valais + TVA.

Il est ensuite possible de configurer les senseur pour l’import / export d’énergie:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
sensor:
  - platform: integration
    name: Grid Import Energy
    source: sensor.grid_import_power
    unit_prefix: k
    unit_time: h
    method: left

  - platform: integration
    name: Grid Export Energy
    source: sensor.grid_export_power
    unit_prefix: k
    unit_time: h
    method: left

ainsi qu’un « utility_meter » pour le tarif:


1
2
3
4
5
6
7
8
utility_meter:
  daily_energy:
    source: sensor.grid_import_energy
    name: Daily Import Meter
    cycle: daily
    tariffs:
      - hp
      - hc

ainsi que l’automatisation pour la bascule du tarif (dans automations.yaml)

En 2024, le tarif heure creuse est valable de 22h à 7h en semaine ainsi que les week-end.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
- id: '<random>'
  alias: HP/HC Romange Energie
  description: ''
  trigger:
  - platform: time
    at: 06:00:00
    variables:
      tariff: hp
  - platform: time
    at: '22:00:00'
    variables:
      tariff: hc
  condition:
  - condition: time
    weekday:
    - mon
    - tue
    - wed
    - thu
    - fri
  action:
  - action: select.select_option
    target:
      entity_id: select.energy_meter_tarif
    data:
      option: '{{ tariff }}'
  mode: single

Sur un tableau de bord simple, cela donne :

Il faut ensuite configurer ces entités dans le module Energie de Home Assistant :

En particulier, préciser le tarif pour la consommation du réseau et l’énergie retournée au réseau:

Résultat (un jour pluvieux):

Nous avons maintenant un coût journalier (actualisé plusieurs fois par jour) qui peut être consolidé par période (semaine, mois, année).

Source: Enphase Envoy with Energy Dashboard – Share your Projects! – Home Assistant Community (home-assistant.io)

Catégorie : Home Assistant | Tag , , | Laisser un commentaire

Configurer Starship avec WSL pour booster sa productivité

Starship est un prompt « cross-shell », amélioré, ultra-rapide et personnalisable.

En cherchant comment personnaliser l’affichage de mon shell dans différente conditions, je suis tombé sur starship qui présente de nombreux avantages:

  • multi-shell
  • compatible avec WSL
  • personnalisable
  • performant, avec un faible impact sur les ressources

L’installation est on ne peut plus simple et est décrite sur la page de documentation. Ci-après, je décris comment l’installer sous n’importe quelle distribution Linux WSL (Debian dans mon cas):

  1. Lancer le script d’installation :
    1
    curl -sS https://starship.rs/install.sh | sh
  2. Ajouter la ligne suivante à la fin de ~/.bashrc
    1
    eval "$(starship init bash)"
  3. Recharge la config bash:
    1
    source ~/.bashrc

Starship est maintenant installé. Vous l’aurez remarqué, l’affichage est un peu « buggé ». C’est normal, il faut encore ajouter une Font supportant les icones. Pour ça, il y a l’excellent site nerdfonts.com. Dans mon cas j’ai choisi le « Hack Nerd Font ». L’installation est on ne peut plus simple:

  1. Télécharger le font (sous Windows)
  2. Ouvrir les fichiers polices souhaités et clicker sur « Installer

Il reste deux étapes importantes à effectuer pour avoir un prompte hyper pratique:

La première, il faut configurer la police installée dans le Terminal Windows: Paramètre -> Debian -> Apparence

La deuxième étape, il faut customiser starship. Ca s’effectuer en éditant le fichier ~/.config/starship.toml.

Exemple de ma configuration (attention, les icônes ne seront pas reprise correctement car la police n’est pas installée sur ce site, il faut les adapter selon votre besoin. Ce fichier se trouve également sur mon repo Github


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
# ~/.config/starship.toml

add_newline = false
command_timeout = 1000
format = """$os$username$hostname$kubernetes$directory$git_branch$git_status"""

# Drop ugly default prompt characters
[character]
success_symbol = ''
error_symbol = ''

# ---

[os]
format = '[$symbol](bold white)'
disabled = false

[os.symbols]
Windows = ''
Arch = '󰣇'
Ubuntu = ''
Macos = '󰀵'

# ---

# Shows the username
[username]
style_user = 'white bold'
style_root = 'black bold'
format = '[$user]($style)'
disabled = false
show_always = true

# Shows the hostname
[hostname]
ssh_only = false
format = '@[$hostname](bold yellow):'
disabled = false

# Shows current directory
[directory]
truncation_length = 10
truncation_symbol = '…/'
home_symbol = '󰋜 ~'
read_only_style = '197'
read_only = '  '
format = '[$path]($style)[$read_only]($read_only_style)> '
truncate_to_repo = true
# Shows current git branch
[git_branch]
symbol = ' '
format = '\([$symbol$branch]($style)\)'
# truncation_length = 4
truncation_symbol = '…/'
style = 'bold green'

# Shows current git status
[git_status]
format = '[$all_status$ahead_behind]($style) '
style = 'bold green'
conflicted = '🏳'
up_to_date = ''
untracked = ' '
ahead = '⇡${count}'
diverged = '⇕⇡${ahead_count}⇣${behind_count}'
behind = '⇣${count}'
stashed = '$ '
modified = ' '
staged = '[++\($count\)](green)'
renamed = '» '
deleted = '✘ '

# Shows kubernetes context and namespace
[kubernetes]
format = 'via [󱃾 $context\($namespace\)](bold purple) '
disabled = true

# ---

[vagrant]
disabled = true

[docker_context]
disabled = true

[helm]
disabled = true

[python]
disabled = true

[nodejs]
disabled = true

[ruby]
disabled = true

[terraform]
disabled = true

Une fois le fichier starship.toml, la prochaine ligne de shell sera directement à jour avec la configuration.

Quelques exemples du résultat dans le Terminal (j’ai masqué mes info host/machine):

La dernière étape consiste à configurer VSCode pour supporter l’affichage. Comme pour le Terminal, il faut lui préciser la police à utiliser, sans quoi, les icônes ne seront pas affichées:

Dans settings.json, ajouter les configurations suivante, selon vos préférences :


1
2
"terminal.integrated.fontFamily": "Hack Nerd Font Mono",
"terminal.integrated.fontSize": 12

Voilà VSCode configurer avec starship dans le terminal WSL. La méthode s’applique dans d’autres terminaux également ce qui permet de retrouver une uniformité entre différents shell avec un niveau élevé de personnalisation assurance un gain en productivité

Catégorie : Windows | Tag , , | Commentaires fermés sur Configurer Starship avec WSL pour booster sa productivité

ElasticSearch sur NAS Synology + Docker

Ce guide va présenter comment configurer ElasticSearch et Kibana sur un NAS Synology avec Docker. Le but n’est pas d’avoir une machine ultra-performante mais de pouvoir avoir une installation ElasticSearch facilement maintenable pour des tests ou juste découvrir l’outil. Il sera ainsi possible de mettre à jour rapidement la version dl’ElasticSearch sans perdre de données grâce à l’utilisation de Docker.

Récupération des images Docker

Récupérer les images elastic/elastic-search et elastic/kibana, ce sont les images officielles. Si vous possédez un Synology équiper d’un processeur 64bit, vous pouvez utiliser l’image amd64.

Création des conteneurs: elasticsearch

Pour créer un conteneur, aller dans Image, sélectionner l’image, puis « Lancer »:

Ensuite, choisir « Paramètres avancés »

Paramètres généraux: choisir le nom du conteneur

Volume: configurez deux dossier, config et data avec accès en écriture. C’est là que seront stockés les configurations ainsi que les données des indexes

Fichier/Dossier: le répertoire sur votre NAS, à définir selon votre structure de répertoire.

Chemin d’accès:

/usr/share/elasticsearch/config

/usr/share/elasticsearch/data

Configurer les ports locaux pour les ports du conteneur 9200 et 9300 du conteneur elasticsearch.

Dans environnement, ajouter le paramètre discovery.type = single-node

Création des conteneurs: kibana

Similaire à elasticsearch:

Pour les ports locaux, attention de bien le spécifier, sans ça, impossible d’accéder à Kibana (port 5601 par défaut)

Configuration elasticsearch et kibana

Dans elasticsearch.yml, activer la sécurité: xpack.security.enabled: true. Pour plus de détail: https://www.elastic.co/guide/en/elasticsearch/reference/7.11/get-started-enable-security.html

redémarrer le conteneur puis, dans le shell, mettre à jour les mots de passe (attention de ne pas les perdre, en particulier celui de kibana_system):
./bin/elasticsearch-setup-passwords interactive

Dans kibana.yml, configurer le mot de passe kibana_system selon ce qui a été défini dans le conteneur elastic. Adapter le port elasticsearch si nécessaire.

Voici le miens:

server.name: kibana
server.host: « 0 »
elasticsearch.username: « kibana_system »
elasticsearch.password: « ********** »
elasticsearch.hosts: [ « http://elasticsearch:9200 » ]
monitoring.ui.container.elasticsearch.enabled: true

Le paramètre elasticsearch.hosts tel que défini nécessite de lier les deux conteneurs:

Démarrer les deux conteneur (vous pouvez lier kibana à elasticsearch pour qu’ils soient démarrés en même temps)

Accéder à l’URL de votre NAS avec le port spécifié pour Kibana, vous devriez avoir la page de login qui s’ouvre, pour ensuite accéder à Kibana.

Catégorie : Coding, ElasticSearch | Tag , , , | Commentaires fermés sur ElasticSearch sur NAS Synology + Docker

Windows 10: installation de WSL2 et Debian

Le build 19013 de Windows 10 est disponible depuis peu pour les Insider du programme « lent » (ie, qui présente le moins de risques d’instabilité):

Configuration en Insider « Lent »

Concrètement, cela permet d’installer WSL2, disponible depuis le build 18917 : https://docs.microsoft.com/en-us/windows/wsl/wsl2-install

Par la suite, il est possible d’installer différentes distributions Linux: Debian, Ubuntu, Alpine, …

shell debian

A suivre: les premières expériences avec WSL2.

Catégorie : Uncategorized | Tag , , | Commentaires fermés sur Windows 10: installation de WSL2 et Debian

Tensorflow sur Google Colab

En voulant tester quelques bouts de code utilisant Tensorflow, j’ai constaté que mon PC datait un peu: il n’a pas de support CPU supportant les instructions AVX.

Une version « raspberry-pi » existe depuis 2018 mais elle est loin de permettre de travailler efficacement. L’exemple classic sur le dataset MNIST prend en effet un temps assez conséquent à s’exécuter:

import tensorflow as tf
mnist = tf.keras.datasets.mnist

(x_train, y_train),(x_test, y_test) = mnist.load_data()
x_train, x_test = x_train / 255.0, x_test / 255.0

model = tf.keras.models.Sequential([
  tf.keras.layers.Flatten(),
  tf.keras.layers.Dense(512, activation=tf.nn.relu),
  tf.keras.layers.Dropout(0.2),
  tf.keras.layers.Dense(10, activation=tf.nn.softmax)
])
model.compile(optimizer='adam',
              loss='sparse_categorical_crossentropy',
              metrics=['accuracy'])

model.fit(x_train, y_train, epochs=5)
model.evaluate(x_test, y_test)

Le résultat avec le raspberry-pi:

pi@raspberrypi:~/tensorflow $ python3 mninst.py 
Downloading data from ...
11493376/11490434 [===] - 2s 0us/step
Epoch 1/5
60000/60000 [===] - 107s 2ms/step - loss: 0.2007 - acc: 0.9407
Epoch 2/5
60000/60000 [===] - 104s 2ms/step - loss: 0.0797 - acc: 0.9758
Epoch 3/5
60000/60000 [===] - 104s 2ms/step - loss: 0.0515 - acc: 0.9835

...

Soit près de 2ms par step.

Depuis une année, Google propose Colab : https://colab.research.google.com qui permet gratuitement un environnement Jupyter avec tensorflow pré-installé. Il y a même des GPU disposition.

CPU:

Epoch 1/5 
60000/60000 [===] - 17s 289us/sample - loss: 0.2223 - acc: 0.9342
Epoch 2/5
60000/60000 [===] - 17s 281us/sample - loss: 0.0969 - acc: 0.9706
Epoch 3/5
60000/60000 [===] - 17s 282us/sample - loss: 0.0696 - acc: 0.9783
Epoch 4/5
60000/60000 [===] - 17s 286us/sample - loss: 0.0532 - acc: 0.9836
Epoch 5/5
60000/60000 [===] - 18s 301us/sample - loss: 0.0442 - acc: 0.9856
10000/10000 [===] - 1s 64us/sample - loss: 0.0715 - acc: 0.9805
[0.07151023466372862, 0.9805]

GPU:

Epoch 1/5 
60000/60000 [===] - 8s 136us/sample - loss: 0.2170 - acc: 0.9358
Epoch 2/5
60000/60000 [===] - 8s 134us/sample - loss: 0.0954 - acc: 0.9718
Epoch 3/5
60000/60000 [===] - 8s 133us/sample - loss: 0.0690 - acc: 0.9781
Epoch 4/5
60000/60000 [===] - 8s 133us/sample - loss: 0.0530 - acc: 0.9830
Epoch 5/5
60000/60000 [===] - 8s 134us/sample - loss: 0.0442 - acc: 0.9853
10000/10000 [===] - 1s 70us/sample - loss: 0.0609 - acc: 0.9807
[0.06085205714175245, 0.9807]

La version CPU sur Colab est plus de 5x plus rapide que sur un raspberry-pi et la version GPU 10x plus rapide (pour l’exemple ci-dessus).

Il peut donc être intéressant de créer ses modèles sur Colab, à condition d’être conscient que Google y a probablement accès…

Catégorie : Uncategorized | Commentaires fermés sur Tensorflow sur Google Colab

Développement Python sous Gentoo sans perturber l’environnement du système

Sous Gentoo, l’environnement Python est particulièrement sensible car il est utilisé par le gestionnaire de packages: portage.
L’outil pip, également utilisable pour installer des paquets Python risque d’interférer avec l’environnement du système.

Il est parfois nécessaire d’avoir des paquets python qui ne sont pas proposé directement par la distribution Gentoo. Dans cette situation, il est préférable d’utiliser virtualenv.

Cet outil permet d’installer un environnement python complètement séparé de celui du système.

Installation:

emerge virtualenv

mkdir ~/virtualenv/dev
cd ~/virtualenv/dev
virtualenv .

activer l’environnement:

source ./bin/activate

et installer les paquets requis

pip install ....

Catégorie : Uncategorized | Tag , | Commentaires fermés sur Développement Python sous Gentoo sans perturber l’environnement du système

Installation environnement crossdev ARM sur Gentoo (x86 32/64)

Il peut être pratique d’avoir un environnement de développement ARM utilisable directement depuis un environnement x86 lorsqu’on ne possède pas d’environnement dédié (périphérique cible, raspberry PI par exemple) ou qu’on ne veut pas émuler tout un système d’exploitation dans Qemu pour lancer un simple binaire.

Les étapes suivantes décrivent comment installer l’environnement de compilation (GCC) ainsi que les outils permettant d’exécuter directement un binaire ARM.

Lire la suite

Catégorie : ARM, Coding, Gentoo | Tag , , , , , , | Commentaires fermés sur Installation environnement crossdev ARM sur Gentoo (x86 32/64)

Bridge Mode avec modem Thomson de UpcCablecom

Il peut arriver que l’on veuille avoir un accès direct au net sans que le modem fasse office de routeur.

Pour se faire, il suffit d’y accéder en utilisant l’URL locale 192.168.100.1 (login/mot de passe par défaut: <vide>/admin).

Ensuite, dans Gateway -> SwitchMode, choisir ‘Disable mode’ au lieu de Legacy RG IPv4 mode.

source: https://support-en.upc-cablecom.ch/app/answers/detail/a_id/6323/~/bridge-mode-with-the-thomson-wlan-modem

Catégorie : Uncategorized | Tag | Commentaires fermés sur Bridge Mode avec modem Thomson de UpcCablecom

Chasse aux ballons

Vidéo de la partie « chasse aux ballons » durant la Vercorun 2014.

Catégorie : Uncategorized | Commentaires fermés sur Chasse aux ballons

Changer le prefix des tables wordpress

Voici la procédure pour changer le préfix d’une installation WordPress existante (par défaut, il vaut ‘wp_’).

Prenons par exemple, un schema test sur lequel se trouve les tables, et que l’on veut changer le préfix wp_ en monPrefix_,  la requête SQL suivante permet de générer les alters requis:

SELECT CONCAT('RENAME TABLE ', GROUP_CONCAT('`', TABLE_SCHEMA, '`.`', TABLE_NAME, '` TO `', TABLE_SCHEMA, '`.`monPrefix_', SUBSTR(TABLE_NAME,4), '`')) ASFROM `information_schema`.`Tables` WHERE TABLE_SCHEMA='test';

Ensuite, ouvrir wp-config.php et modifier la valeur de la variable : $table_prefix en ‘monPrefix_‘.

On pourrait croire que les étapes ci-dessus sont suffisantes, mais au moment d’accéder à la console d’administration, le message suivant apparaît:

Vous n’avez pas les droits suffisants pour accéder à cette page

Il faut encore modifier les valeurs en base de donnée qui sont basées sur ce préfix :

  • dans la table wp_options, pour la ligne la ligne dont le champ option_name vaut wp_user_roles , il faut le modifier en monPrefix_user_roles
  • de même, dans la table wp_usermeta, il faut changer le prefix de toute les lignes ayant comme valeur de champ meta_key les valeurs suivantes :
    • wp_autosave_draft_ids,
    • wp_capabilities,
    • wp_usersettings,
    • wp_usersettingstime 

    deviennent :

    • monPrefix_autosave_draft_ids,
    • monPrefix_capabilities,
    • monPrefix_usersettings
    • monPrefix_usersettingstime 
Catégorie : Coding, PHP | Tag , | Commentaires fermés sur Changer le prefix des tables wordpress