Charging Station & Modbus Active Loadbalancing

Charging Station Model: Alfen ng910-60027 – Eve single pro-line 3PH cable
Energy metering Socomec Countis E27

This setup is using Modbus “Slave 1” in contrary to default Alfen “Slave 5” configuration.

Configuration tool: ACE Service Installer 3.6.10 – You need to request a username and password at the supplier prior to be able to use their tool.

Home assistant config

# ModBus
modbus:
  - name: "countis"
    type: tcp
    host: 192.168.10.4
    port: 502
    sensors:
############## Stroom #################
      - name: countis_current_total
        address: 50534
        data_type: uint32
        slave: 1
        scale: 0.001
        unit_of_measurement: A
      - name: countis_current_i1
        address: 50528
        data_type: uint32
        slave: 1
        scale: 0.001
        unit_of_measurement: A
      - name: countis_current_i2
        address: 50530
        data_type: uint32
        slave: 1
        scale: 0.001
        unit_of_measurement: A
      - name: countis_current_i3
        address: 50532
        data_type: uint32
        slave: 1
        scale: 0.001
        unit_of_measurement: A
############## Vermogen #################
      - name: countis_active_power_phase1
        address: 50544
        data_type: int32
        slave: 1
        scale: 10
        unit_of_measurement: W
      - name: countis_active_power_phase2
        address: 50546
        data_type: int32
        slave: 1
        scale: 10
        unit_of_measurement: W
      - name: countis_active_power_phase3
        address: 50548
        data_type: int32
        slave: 1
        scale: 10
        unit_of_measurement: W
      - name: countis_active_power_sum
        address: 50536
        data_type: int32
        slave: 1
        scale: 10
        unit_of_measurement: W
############## Energie totalen #################
      - name: countis_net_residual_active_energy_balance
        address: 33026
        data_type: uint16
        slave: 1
      - name: countis_net_active_energy_balance
        address: 33024
        data_type: uint32
        slave: 1
############## Energie totalen per tarief in kWh #################
      - name: countis_net_active_energy_balance_tariff1
        address: 26369
        data_type: uint32
        slave: 1
        unit_of_measurement: kWh
      - name: countis_net_active_energy_balance_tariff2
        address: 26371
        data_type: uint32
        slave: 1
        unit_of_measurement: kWh
############## Actief tarief #################
      - name: countis_net_active_tariff
        address: 26368
        data_type: uint16
        slave: 1

TRC270F – KNX Tussenstekker

Hager TRC270F – draadloos knx 230v relais

 

Nu ik eindelijk dacht dat KNX geen geheimen meer had voor mij kwam ik toch wel vast te zitten bij het configureren van een nieuwe draadloze knx relais. Bovenstaande tussenstekker schakelt een belasting op 230v.

Vol goede moed voegde ik dit toestel toe op mijn RF lijn van mijn ETS project. Als 5de draadloze busdeelnemer.

Even een refresh: Een draadloze lijn voor de hager mediacoupler onder te brengen gebeurt niet op een RF lijn maar op een TP lijn. Verder wordt er als eerste device dan een Hager Media Coupler geplaatst welke .0 als busdeelnemer adres heeft.

Nieuwe groepsadressen aanmaken en koppelen

Nadien volgt het starten van de configuratieplugin (openen onder de parameter tab van 1.2.0 Media coupler)

Hier ging alles heel vlot:

1. Onder physical addressing het nieuwe toestel zoeken. Aangezien deze de fabrieksinstellingen had kwam de nieuwe TRC270 automatisch in de lijst.
2. Fix address procedure uitvoeren
3. Download van parameters uitvoeren
4. Physical effect testen ==> OK

Alles werkte perfect en ik dacht dat ik na een kwartiertje werk reeds klaar was.

Toen ik het toestel in productie bracht kwam ik tot de vaststelling dat er niets gebeurde!

Al snel keek ik via de busmonitor en zag dat er geen telegrammen van de nieuwe TCR270 op de bus terechtkwamen.

Na contact met support van Hager bleek er een filtering op de groepsadressen aanwezig te zijn. Wanneer er een nieuw groepsadres aangemaakt wordt kan deze standaard niet tussen verschillende lijnen communiceren. (Filtered)

De oplossing was op het niveau van de groepsadressen een parameter aan te passen zodat de groepsadressen van de TRC270 weldegelijk tussen verschillende lijnen mag communiceren.

(Of in het Engels Pass through line coupler) aanvinken en nadien de download opnieuw uitvoeren via de media coupler plugin.

De enige vraag dat nog openstaat is waarom mijn draadloze afstandsbedieningen (Hager TU402) en draadloze rookmelders (Hager TGA510A) wel kunnen communiceren. (Zonder niet filteren aan te zetten!) Ik gebruik deze KNX componenten reeds enkele jaren en doen het perfect.

Watermeter

Gebruikte materialen

Arcus-EDS
KNX-GW-MBUS REG

Maddalena FlowPulse M-Bus Counter

Analoge watermeter

Maddalena MVM – POSITIVE DISPLACEMENT ROTARY PISTON WATER METER

KNX Config

MBus DPT Identifier
The M-Bus was developed for configuration and reading of data from meters and consumption counting devices. The M-Bus is a
bus with a single master that powers and reads out multiple slave devices. Each slave is addressable with an individual ID that is
between 1 and 250. Theoretically up to 250 slave devices could be operated in one M-Bus segment, but the practical number is
determined by the ability of the master to power the devices. The topology is not critical and no termination is required. Maximum
bus length is 4km in theory depending on the baudrate, in practical situations not more than 10m should be aspired for good
noise immunity.
The M-Bus gateway can power up to 3 devices and communicate with them. If only one device is present, this can be addressed
independent of its individual ID with the broadcast ID ( 254 ). This simplifies the configuration of such a minimal system.
Some M-Bus devices can be powered through the M-Bus, others draw current from the internal battery at readout of the data. So
some M-Bus devices only allow a certain number of readings over an amount of time to disburden the internal batteries. The
readout cycles must be choosen accordingly.
Readout of the devices data is initiated by the master by sending a REQ_UD2 ( Request User Data ) telegram. The connected
devices check if they are addressed by comparing their ID and return a RSP_UD ( Respond User Data ) telegram. The RSP_UD
telegram contains up to 252 byte of user data. The user data consists of several data packages each of them beginning with
some identification bytes, the DIF ( Data Information Field ) and the VIF ( Value Information Field ). DIF and VIF can have several
byte, of practical relevance are 1 or 2 byte per field. With 4 byte nearly all data packages can be identified. If a value field
represents a reference value there is usually a date field associated with this value. The information that can be expected in the
DIF and VIF are different with every manufacturer and every device class. Generally the desired informations can be achieved
from the manufacturers. The values for the DIF and VIF must be identified and written into the appropriate fields as strings of
hexadecimal characters.
Water meter
Volume information DIF 04 VIF 13 Data to write into the parameter field: 0413
Reference value DIF 04 VIF 80 13 Data to write into the parameter field: 048013

Electrical Meter
Total consumption DIF 04 VIF 03 Data to write into the parameter field: 0403
Actual consumption DIF 02 VIF 2B Data to write into the parameter field: 022B

Hassio Update

Added offset 16,402 to reflect identical meter value

sensor.yaml

water_consumption_m3:
friendly_name: “Total Water Consumption m3”
unit_of_measurement: ‘m3’
value_template: “{{ (states(‘sensor.waterarcus’)|float / 1000 + 16.402) | round(0) }}”

Gasmeter in Hager Domovea

1: Cumulatieve waarde
Totaal verbruik op KNX bus in m³

2: Momentane waarde
Actief verbruik op KNX bus in m³ / uur

3: Stapgrootte
Aangezien ik tot 2 cijfers na de komma als 1 decimaal getal op de bus verstuur dien ik de stapgrootte aan te passen van 1 naar 0.01. Bv: 670125 op de KNX bus is 6701,25 m³

De correcte momentane waarde visualiseren was een ander paar mouwen. Het moeilijkste stuk was achterhalen welke waarde de Hager TJA450 gebruikt om het momentaan gasverbruik uit te lezen. Na het uittesten van verschillende bus writes via de domovea configuration tool (automatisering) ben ik erachter gekomen dat er een 4 bytes float waarde nodig is vooraleer de Gauss meter in beweging treedt.

Na het testen van de verschillende datapoints had ik eindelijk succes met de 4 bytes Float value.

Hier merkte ik ook op dat na het verzenden van de waarde 1 de Gauss meter in de visualisatie 3600 m³ gas aangaf. Dit nam ik mee voor de latere berekening dat ik hoogstwaarschijnlijk nog eens mijn momentaan verbruik zal moeten delen door 3600 (of vermenigvuldigen met 0.000278)

Een 2de obstakel was mijn float waarde van het momentane verbruik omzetten naar een hexadecimale waarde. Ook dit heb ik uiteindelijk kunnen verwezenlijken door het gebruik van een python scriptje. Vanuit bash roep ik een python functie op en gebruik de return value ervan als hexadecimale waarde.

Het script loopt via crontab elke minuut en zal 5x dezelfde waarde in deze minuut op de bus uitsturen (elke 10 seconden). 1 update van het momentaan gasverbruik per minuut lijkt me voldoende. De reden om de waarde elke 10 seconden op de bus uit te sturen is omdat de domovea visualisatie na 20 seconden > durft terug te vallen op 0.

Gebruikte scripts:

crontab config

crontab -e
*/1 * * * * /root/scripts/knxScripts/gasToBus.sh

Bash script

#!/bin/bash
# Uitlezen gaswaarde via TRC5000 en RPI3
# Via crontab elke minuut momentaan verbruik starten, dit script zal 5x 10 seconden slapen en dezelfde waarde versturen
log="/root/logs/gasToBus.log"

# ophalen huidig gasverbruik
consumption=$(</var/run/shm/gascounter)

# ophalen vorig gasverbruik
pconsumption=$(</root/scripts/knxScripts/gasToBus.lastdata)

# berekenen nieuw verbruik
nconsumption=$(expr $consumption - $pconsumption)

# omzetten naar m^3/h
# script loopt elke 60 seconden
# 0,01 = 1 puls
# nconsumption = aantal nieuwe pulsen in 1 minuut
# nconsumption x 60 = aantal pulsen / uur
# hconsumption = hourly consumption
# 1/3600 = 0,000278 => 4 byte floatwaarde hourly consumption
hconsumption=$(echo $nconsumption*60/100 | bc -l)
hconsumption=$(echo $hconsumption*0.000278 | bc -l)

#afronden niet nodig
#hrconsumption=$(echo "($hconsumption)/6" | bc)

hexbusformat=`python /root/scripts/knxScripts/floatToHex.py "$hconsumption"`

#echo "$hrconsumption -> $whex"
#printf -v hexconsumption "%08x" "$hrconsumption"
#hexbusformat=$(echo $hexconsumption | sed 's/.\{2\}/& /g')

#echo "$(date "+%Y%m%d %T") Wegschrijven momentaan verbruik op KNX bus 4/6/16 -> dec: $hconsumption -> hex: $hexbusformat" >> $log
for i in {1..5}
do
 knxtool groupwrite local:/run/knx 4/6/16 $hexbusformat
 #echo "$(date "+%Y%m%d %T") iteratie $i -> write $hexbusformat done" >> $log
 sleep 10
done

# wegschrijven van nieuwe lastdata
#echo "$(date "+%Y%m%d %T") wegschrijven momentaan verbruik naar lastdata > $consumption" >> $log
echo $consumption > /root/scripts/knxScripts/gasToBus.lastdata
echo "$(date "+%Y%m%d %T") 5x groupwrite 4/6/16 -> $hexbusformat" >> $log

Python script

#!/usr/bin/python
import struct
import os
import sys
def float_to_hex(f):
return hex(struct.unpack('<I', struct.pack('<f', f))[0])
whex = float_to_hex(float(sys.argv[1]))
whex = whex.replace('0x','')
whex=' '.join([whex[i:i+2] for i in range(0, len(whex), 2)])
if whex == "0":
print "00 00 00 00"
sys.exit(0)
else:
print whex
sys.exit(0)

#whex = float_to_hex(0.000556)
#print whex
#plaats hexadecimaal telegram op de bus (via bash commando)
#wcommand = "knxtool groupwrite local:/run/knx 4/6/16 " + whex
#os.system(wcommand)

 

Het resultaat:

Gas & waterteller op RPI

Gebruikt materiaal

• DIY Hall Switch Hall Sensor Module for Smart Car – Blue
• RPI3
• Verlengde dupont kabeltjes

 

Foto van de Hall Sensor

Er werd voor een Hall sensor gekozen omdat een reed sensor onderhevig is aan metaalmoeheid.

In mijn eerste testopstelling maakte ik gebruik van een TCR5000 dit is een optische infrarood LED. De idee was om het blinkende embleempje onder de 6 van mijn gasteller uit te lezen maar omwille van het plexiglas en het miniscule embleempje was het niet mogelijk om de weerkaatsing in orde te krijgen.

Foto van een optische TCR5000 infrarood reflector

 

UPDATE: Met heel veel toeval heb ik alsnog de correcte positie van de TCR5000 op de gasmeter gevonden. Plexiglas is ook niet onderhevig aan de weerkaatsing van het infraroodlicht. 

 

Zowel de TCR5000 als de Hall sensor komen met een digital output en een potentiometer om de gevoeligheid te regelen. De totale kostprijs van dit printje is 1.5 EUR en hiervoor kan je onmogelijk zelf een opstelling in elkaar boxen.

Beide sensors komen ook met een LED lampje welke brandt wanneer de Digital Output High is. Hiermee kan je heel eenvoudig en zonder programmeerwerk de werking van de sensor testen.

 

RPI Configuratie

Aangezien het de eerste GPIO pinnen zijn die ik zal gebruiken op mijn RPI bordje dien ik nog de WiringPi module te installeren.

http://wiringpi.com/

git clone git://git.drogon.net/wiringPi
cd /wiringPi
./build

 

Versiecontrole na installatie

 gpio -v

gpio version: 2.44
Copyright (c) 2012-2017 Gordon Henderson
This is free software with ABSOLUTELY NO WARRANTY.
For details type: gpio -warranty
Raspberry Pi Details:
 Type: Pi 3, Revision: 02, Memory: 1024MB, Maker: Sony
 * Device tree is enabled.
 *--> Raspberry Pi 3 Model B Rev 1.2
 * This Raspberry Pi supports user-level GPIO access.

 

Gebruikte GPIO pinnen

 

GPIO PIN 2 : +5V Hall Sensor
GPIO PIN 12 : DO (Digital out) Hall Sensor (WiringPI NUMMER = 1)
GPIO PIN 14 : GND Hall Sensor

 

Opvragen van de GPIO pinnen met WiringPI

root@raspberrypi:~ # gpio readall

 

Het voordeel van het aanspreken van de GPIO pinnen via de WiringPI nummering is dat deze nummers niet onderhevig zijn aan hardware changes. D.w.z. dat bij gebruik van de WiringPI library kan overgeschakeld worden naar andere hardware zonder de noodzaak om code te herschrijven.

 

Op domoticz.com heb ik een mooi c programma gevonden welke de sensor kan pollen

https://www.domoticz.com/forum/viewtopic.php?f=32&t=3151&start=60#p112272

Dit heb ik als basis gebruikt om het programma gascounter en watercounter te compileren. De enige aanpassing in de C-code is de WiringPi ID waarop de puls binnenkomt.

 

gcc -o gascounter gascounter.c –lwiringPi

// What GPIO input are we using?
// This is a wiringPi pin number
#define IN_PIN 1
#define INTERRUPT_DEBOUNCE_DELAY 500

IN_PIN GAS = 1
IN_PIN Water = 4

Hierna het programma compileren:

gcc -o gascounter gascounter.c –lwiringPi

Verplaatsen van programma naar default linux locatie

mv gascounter /usr/local/bin

Startwaarde eenmalig instellen

echo 300 > /var/run/shm/gascounter

SHM = Shared memory -> de counter telt in het virtuele geheugen. Pas bij een start / stop schrijft hij de waarde weg naar persistent storage. Dit gebeurt via het service script:

vim /etc/init.d/gascounter
SAVEFILE="/root/counters/$NAME"

Meer info:
https://www.cyberciti.biz/tips/what-is-devshm-and-its-practical-usage.html

Verdere vars aanpassen en startup script optimalisatie

vim /etc/init.d/gascounter
chown root:root /etc/init.d/gascounter
chmod 755 /etc/init.d/gascounter

Testen van het c-programma in de voorgrond (zonder service script)

 vim /etc/init.d/gascounter
root@raspberrypi:~ #/usr/local/bin/gascounter /var/run/shm/gascounter /root/counters/gascounter /root/logs/gasmeter.log
Usage: /usr/local/bin/gascounter tempfilename storagefilename logfilename

Activeren van de daemon

systemctl daemon-reload
systemctl enable gascounter
systemctl start gascounter

Autostart & monitoring via MONIT

vi /etc/monit/monitrc
check process GAS_Meter matching "/usr/local/bin/gascounter"
start program "/etc/init.d/gascounter start"
stop program "/etc/init.d/gascounter stop"

monit status
monit reload

Kleine optimalisatie: (vastgesteld van warning tijdens starten service -> systemctl status gascounter:

chmod 755 /root/counters/gascounter

Zelfde config aanmaken voor de watercounter

watercounter.c
GPIO_PIN = wiringPI number 4

gcc -o watercounter watercounter.c –lwiringPi
mv watercounter /usr/local/bin/
cp /etc/init.d/gascounter /etc/init.d/watercounter
echo 600 > /var/run/shm/watercounter

systemctl daemon-reload
systemctl enable watercounter
systemctl start watercounter

vi /etc/monit/monitrc
check process watercounter matching "/usr/local/bin/watercounter"
start program "/etc/init.d/watercounter start"
stop program "/etc/init.d/watercounter stop"

chmod 755 /root/counters/watercounter

monit status
monit reload

 

Handig commando om elke second de huidige tellerstand uit te lezen (om te debuggen)

while sleep 1; do cat /var/run/shm/gascounter; echo ""; done

Druktoets garagepoort

In de garage staat een druktoets (WKT304) welke een relais (TXA204C -A2) schakelt. Op deze relais is het analoge contact van de motor van de garagepoort (marantec comfort 220.2) aangesloten.

De druktoets is geconfigureerd als een ON / OFF schakeling (Dus geen teleruptor) en dit zodat de TXA204C – A2 uitgeschakeld wordt bij het loslaten van de druktoets. In tegenstelling tot een teleruptor (welke ON zou blijven bij het loslaten) zal je bij een volgende druktoets terug een signaal sturen naar de motor.

OPGELET:

De motor heeft tijd nodig om het signaal te kunnen opvangen. Bij een zeer snelle druktoets (bv kleiner dan 200ms) is de motor niet in staat het signaal op te vangen. Hiervoor heb ik op de druktoets in de garage een afvalvertraging van 500ms moeten configureren. DWZ wanneer er heel snel op de druktoets geduwd wordt zal de relais pas +500ms later uitschakelen.

 

Garagepoort op domotica

Type motor: Marantec Comfort 220.2

Aansluiten potentiaal vrij contact

1 = ground
2 = puls

 

Doorverbonden in de domoticakast met een Hager TXA204C-A2 (contact 4)

KNX addresses:

4/0/0 = on / off
4/0/1 = status indicatie
4/0/2 = timer object

230v deurbel i.c.m. klassieke belknop

Materiaal

Gebruikte gong: Friedland D3230 – Big Beng – 230v

Gebruikte deurbel: Niko

KNX input: Hager TX302 (2 kanalen)

KNX output: Hager TXA201B (1 kanaal 230v)

Configuratie

De Niko deurbel wordt aangesloten op 1 van de 2 kanalen van de TX302.

Het relais van de KNX output wordt aangesloten op klemmen 1 en 3 van de Friedland gong.

De transfo van de gong wordt voorzien van 230v.

Initieel had ik de deurbel aangestuurd via een ON/OFF schakeling op de KNX input TX302. Wanneer er een bezoeker op de deurbel duwde werd de KNX output TXA201B geschakeld. Op deze manier emuleerde ik de situatie wanneer er een analoge drukknop zou aangesloten zijn op de klemmen 1 en 3 van de gong. Na programmatie en testen bleek dit zoals verwacht te functioneren. De deurbel deed “DING” bij het indrukken van de knop. Wanneer ik de knop loste kwam de “DONG”.

Na een tijdje bleek dat sommige bezoekers op de deurbel duwde en er helemaal niets gebeurde. Na analyse had dit te maken met het feit dat deze bezoekers enorm snel op de bel duwden. (<200ms)

Bij een klassieke situatie worden de klemmen 1 en 3 kortgesloten, hoe kort je ook maar op de deurbel duwt. Hier treedt dus nooit een probleem op. Bij mij is de INPUT en de OUTPUT van elkaar gescheiden en wordt er eerst via KNX telegrammen gecommuniceerd.

Na de analyse werd duidelijk dat de input wel degelijk het telegram op de bus plaatste. Hiermee wist ik dat ik aan de slag zou kunnen om het probleem bij de output op te lossen.

De oplossing was relatief eenvoudig: i.p.v. een ON/OFF input signaal te versturen heb ik de TX302 geherprogrammeerd om een TIMER object uit te sturen. Op mijn KNX output heb ik een timer van 1 seconde ingesteld en zo schakelt hij in alle gevallen langer dan 200ms.

Het resultaat:

Snel op de knop duwen aan de voordeur: telegram op BUS , output schakelt in = DING –> TIMER 1seconde –> output schakelt uit = DONG

Blijven duwen op de knop aan de voordeur: Ook hier volgt nu de DONG na 1 seconde. Dit is dus verschillend met een klassieke situatie zonder KNX. Maar een deurbel dient natuurlijk niet om te blijven op duwen. In feite is het nu zelfs beter want de transfo blijft nu niet onder spanning staan voor zolang er iemand blijft duwen op de knop.

ETS5 Configuratie

 

UPDATE:

Blijkt na een tijdje dat ik vastgesteld heb dat de TXB302 2 soorten lang duwen ondersteunt.

In de praktijk gebeurt er niets bij een druktoets langer dan 1 seconde i.c.m. het timer object. Dus nu had ik het probleem als iemand langer dan 1 seconde duwde dat er ook geen GONG optrad. Nu zal er waarschijnlijk niemand langer dan 1 sec op deze knop duwen maar het is niet ideaal.

Na wat verder zoeken ben ik op een 2de en betere oplossing gekomen. Ik maak nu terug gebruik van de klassieke ON/OFF op de TXB302. Op de TXB201a heb ik een optie gevonden om een tijdsvertraging voor uitschakelen in te stellen. Hier heb ik 0,5 seconden gekozen. Dus het contact wordt met 0,5 seconden vertraagd vooraleer deze uitschakelt.

Hierdoor elimineer ik ook het probleem dat er niet korten dan 0,5 seconden op de bel kan geduwd worden. (waardoor de DING DONG soms niet optrad)

 

Visualisatie

Website visualisatie in aanmaak.

• php
• mysql
• twig template engine
• mobile friendly css
• json
• highcharts
• bash scripting

 

 

 

NFS RPI3 -> NAS

NAS

NFS inschakelen

Toegang toestaan voor de RPI

Zorg er ook van dat de firewall NFS niet blokkeert!

RPI3

cat /etc/fstab

192.168.10.5:/volume2/data /mnt/nasdata nfs rw 0 0
192.168.10.5:/volume1/web /mnt/nasweb nfs rw 0 0

reboot RPI3 of

mount /mnt/nasweb
mount /mnt/nasdata