How can you reduce your electricity consumption to both lower your bills and help save the planet? Of course, you can be mindful on a daily basis-not leaving lights on unnecessarily, or avoiding excessive use of your electric heating system. But it’s much more effective if you can monitor and compare your consumption in real time, from anywhere. This allows you to measure improvements over time, and to detect and be alerted to unusual activity whether you’re at home or on vacation.

In this article, I’ll explain how I monitor my electricity usage using the Jeedom automation system with a French electricity meter. My setup includes a “master” Jeedom controller (running in a Debian VM hosted on an Intel NUC with vSphere), and a hardware modem/sensor connected to the electricity meter and to a remote Raspberry Pi 3B+. The solution I describe here is actually a standard approach for any scenario where you need to use a remote USB device locally on another computer via a network: USB over IP.

My electricity meter is far from my Jeedom virtual machine, so I cannot plug the electricity modem (which uses USB) directly into the NUC. Therefore, I installed a small Raspberry Pi 3B+ inside the electricity cabinet, connected to the electricity modem. The data collected by the modem from the meter is sent over IP by the Raspberry Pi to the main Jeedom controller, which receives it as if the electricity modem were physically and locally connected. The data is then recorded and displayed nicely over time, allowing us to compare consumption across months and years. With some fine-tuning, it can even calculate your electricity costs. When you combine this with a few Z-Wave sensors, plugs, or switches that monitor their own consumption, you can quickly optimize your overall usage by checking when and where you are consuming the most electricity.

Note that there are two alternatives to this USB over IP approach for Jeedom:

• The first is to deploy a “slave” Jeedom instance on the Raspberry Pi inside the electricity cabinet, and use the Teleinfo plugin + the “Jeedom Link” plugin to transmit data from the slave to the main Jeedom controller. However, this is a heavier setup just to forward data as we need two instances of Jeedom.
• The second is to use the “daemon mode” of Jeedom’s Teleinfo plugin on the Raspberry Pi. This plugin is dedicated to electricity consumption monitoring in Jeedom. Daemon mode does not require a full Jeedom installation on the Raspberry Pi, but I prefer the USB over IP solution because it can be used for any USB device-not just my electricity sensor, and not just for Jeedom.

Therefore, the solution described here using USB over IP is quite a standard solution for any case where you could need to use a remote USB device over a network.

The hardware & Software I use

First a quick overview of the “internal” stuff needed.

• My main Jeedom controller is hosted on a Debian Virtual Machine running on my old Intel Nuc (setup already described here),
• The electricity modem is plugged by using USB on a Raspberry Pi3b (it could probably run on a Pi Zero W), which will permanently sit in the electrical cabinet,
• An “EDF Téléinformation Modem” … Here is the tricky part, every country has I guess its own type of electrical metering system. This tutorial is therefore specific to a French installation ! In France, ALL electrical meters are indeed equipped with 2 wires you can use to monitor the consumption. The data sent over the wires is very simple (officially documented), and this modem converts it in USB data that the raspberry will handle. You NEED to check how your electrical system works in your country and what kind of hardware setup you need to adapt this tutorial to your own country.

• Some basics electrical wires,
• Some kernel modules for the Raspbian (electricity modem) & the Debian (main jeedom controller) + some setup.
• The “Teleinfo” plugin (free) to monitor & record live data on the main Jeedom controller, from the remote sensor,
• The “Suivi conso” Jeedom plugin (8€), which will be used on the main Jeedom controller, to nicely format & display the collected data,

1. Configuration of the remote RPI3B (acting as a “server”)

First, I’ll simply deploy a new Raspbian image on the Raspberry Pi3B. I wrote a small tutorial about this, and i’ll start here from the end of the tutorial.

a. Modem wiring

First, we will need to wire the Teleinfo modem. Unscrew its case, insert two small wires in the case, and each one in one of the two different internal connectors.

Then we need to remove the electricity meter top case, by pulling it gently from the bottom, so that we can get access to its I1 & I2 wire connectors.

Ok we can have access to I1 & I2, we don’t care about the “A” connector. Simply insert the 2 wires coming from the Teleinfo modem in those two connectors. You don’t need to worry about which wire you plug in which connector, it doesn’t have any importance.

And now last but not least, i’ll shut down the raspberry, move it into the electrical cabinet, and boot it.

Once it’s booted, I’ll SSH it and check the USB devices currently seen by Raspbian, and monitor the main system logs so that I can verify the USB teleinfo modem is well detected when i’ll plug it on the raspberry.

And now I plug the modem …

We can see a new “Cartelectronic” product (from messages), identified as a “Future Technology” device (from lsusb) detected as a USB Serial modem on ttyUSB0 (from syslog), which seems perfect.

b. Sharing the Teleinfo data over IP

We start the raspbian tuning. As the RPI3b will share its Teleinfo Data over the TCP/IP network, it’s considered as a Server. We will need the “usbip” package.

apt-get install -y usbip

This will install the required usbip modules. We will now tell Raspbian to start the required kernel modules at boot time by modifying /etc/modules-load.d/modules.conf

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

vhci-hd
usbip-core
usbip_common_mod
usbip-host

Then I recommend to reboot, and check that the usbip modules are loaded:

We can also check which devices are seen by usbip:

root@PITeleinfo:~# usbip list -l
usbip: error: Protocol spec without prior Class and Subclass spec at line 23299
 - busid 1-1.1 (0424:ec00)
   Microchip Technology, Inc. (formerly SMSC) : SMSC9512/9514 Fast Ethernet Adapter (0424:ec00)

 - busid 1-1.5 (0403:6015)
   Future Technology Devices International, Ltd : Bridge(I2C/SPI/UART/FIFO) (0403:6015)

Notice the error on the first line … It seems specific to the Debian 10.12 Bullseye i deployed on the PI3B, but it does not seem to have any impact on the setup. The important information here is the “1-1.5” identifier for the device we want to share (it was also displayd in /var/log/messages & syslog), we will reuse it on the distant host. But first let’s make a quick test of sharing our modem:

root@PITeleinfo:~# usbipd -D
root@PITeleinfo:~# usbip bind -b 1-1.5
usbip: info: bind device on busid 1-1.5: complete

No error, sharing seems OK on the server …

c. Starting the whole thing at boot with systemd

We will create a systemd unit to start usbip at boot, through the file /etc/systemd/system/usbip.service. I followed the information given here (with a few modifications for the Debian/Raspbian).

root@PITeleinfo:~# joe /etc/systemd/system/usbip.service

[Unit]
Description=Exports USB device over IP
Requires=systemd-networkd-wait-online.service
After=systemd-networkd-wait-online.service

[Service]
Type=simple
Restart=on-failure
RestartSec=20
User=root
Group=root
ExecStart=/usr/sbin/usbipd
ExecStartPost=/usr/sbin/usbip bind --busid=1-1.5
ExecStop=/usr/sbin/usbip unbind

[Install]
WantedBy=multi-user.target

Next we tell systemd to handle this new unit, and configure it to be launched at startup.

root@PITeleinfo:~# systemctl daemon-reload
root@PITeleinfo:~# systemctl enable usbip.service
Created symlink /etc/systemd/system/multi-user.target.wants/usbip.service → /etc/systemd/system/usbip.service.

Notice that we told the unit to wait for to be loaded; because .. if the network is not finished to be loaded, we can not share any usb device over the network 😀 So we need to make sure the systemd unit on which we have a dependency to know if the network is UP or not, is enabled on the system.

root@PITeleinfo:~# systemctl enable systemd-networkd-wait-online.service

Now we try to launch the service.

root@PITeleinfo:~# systemctl start usbip.service
Job for usbip.service failed because the control process exited with error code.
See "systemctl status usbip.service" and "journalctl -xe" for details.

We can see an error, let’s check why but I guess this is normal as we already manually launched usbip and a binding earlier, to test it.

root@PITeleinfo:~# journalctl -xe
avril 03 13:02:20 PITeleinfo systemd[1]: Starting Exports USB device over IP...
░░ Subject: L'unité (unit) usbip.service a commencé à démarrer
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ L'unité (unit) usbip.service a commencé à démarrer.
avril 03 13:02:20 PITeleinfo usbip[1634]: usbip: error: device on busid 1-1.5 is already bound to usbip-host
avril 03 13:02:20 PITeleinfo systemd[1]: usbip.service: Control process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStartPost= process belonging to unit usbip.service has exited.
░░
░░ [...]
░░
░░ L'unité (unit) usbip.service a échoué, avec le résultat failed.
root@PITeleinfo:~#

There is a clear explanation: the device busid 1-1.5 is already bound, which is normal as we tested it.

Now let’s restart the PI3B, and verify if usbip is launched and device 1-1.5 automatically shared.

root@PITeleinfo:~# /sbin/reboot

root@PITeleinfo:~# tail -n 300 /var/log/syslog

[...]
Apr  3 18:06:35 PITeleinfo dhcpcd[440]: wlan0: soliciting an IPv6 router
Apr  3 18:06:35 PITeleinfo dhcpcd[440]: wlan0: rebinding lease of 192.168.1.46
Apr  3 18:06:35 PITeleinfo dhcpcd[440]: wlan0: probing address 192.168.1.46/24
Apr  3 18:06:37 PITeleinfo ModemManager[491]: <info>  [base-manager] couldn't check support for device '/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5': not supported by any plugin
Apr  3 18:06:37 PITeleinfo ModemManager[491]: <info>  [base-manager] couldn't check support for device '/sys/devices/platform/soc/3f300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1': not supported by any plugin
Apr  3 18:06:37 PITeleinfo ModemManager[491]: <info>  [base-manager] couldn't check support for device '/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1': not supported by any plugin
Apr  3 18:06:37 PITeleinfo systemd-networkd[169]: wlan0: Gained IPv6LL
Apr  3 18:06:37 PITeleinfo systemd[1]: Finished Wait for Network to be Configured.
Apr  3 18:06:37 PITeleinfo systemd[1]: Starting Exports USB device over IP...
Apr  3 18:06:37 PITeleinfo usbip[558]: usbip: info: bind device on busid 1-1.5: complete
Apr  3 18:06:37 PITeleinfo systemd[1]: Started Exports USB device over IP.
[...]

2. Configuration of the main Jeedom controller

a. Mounting the remote USB device

Here again, we start the Debian tuning. Here, the Jeedom VM is considered as the Client of our RPI3b usbip server. We install the same usbip package.

root@DEBIAN10-3-JEEDOM:~# apt-get install -y usbip

This will install the required usbip modules. We will now tell Debian/to start the required kernel modules at boot time by modifying /etc/modules-load.d/modules.conf

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

vhci-hcd
usbip-core
usbip_common_mod

Then again I recommend to reboot, and check that the usbip modules are loaded:

Now let’s make a quick test, we try to connect to the device we shared previously on the server.

root@DEBIAN10-3-JEEDOM:~# usbip attach -d 1-1.5 -r 192.168.1.46
root@DEBIAN10-3-JEEDOM:~#

Here again, no error, let’s check the USB devices seen by the system. First we check the system logs …

root@DEBIAN10-3-JEEDOM:~# tail -f /var/log/syslog
Apr  3 11:25:41 DEBIAN10-3-JEEDOM kernel: [ 1084.463477] usb 3-1: SerialNumber: DA1RP5XM
Apr  3 11:25:41 DEBIAN10-3-JEEDOM kernel: [ 1084.496260] usbcore: registered new interface driver usbserial_generic
Apr  3 11:25:41 DEBIAN10-3-JEEDOM kernel: [ 1084.496671] usbserial: USB Serial support registered for generic
Apr  3 11:25:41 DEBIAN10-3-JEEDOM kernel: [ 1084.505932] usbcore: registered new interface driver ftdi_sio
Apr  3 11:25:41 DEBIAN10-3-JEEDOM kernel: [ 1084.506646] usbserial: USB Serial support registered for FTDI USB Serial Device
Apr  3 11:25:41 DEBIAN10-3-JEEDOM kernel: [ 1084.507371] ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected
Apr  3 11:25:41 DEBIAN10-3-JEEDOM kernel: [ 1084.507474] usb 3-1: Detected FT-X
Apr  3 11:25:41 DEBIAN10-3-JEEDOM kernel: [ 1084.512422] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0
Apr  3 11:25:44 DEBIAN10-3-JEEDOM ModemManager[492]: <info>  Couldn't check support for device '/sys/devices/platform/vhci_hcd.0/usb3/3-1': not supported by any plugin

A new USB device was mounted, fine. Then we check the USB device is officially listed.

root@DEBIAN10-3-JEEDOM:~# lsusb
Bus 018 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 017 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 016 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 015 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 014 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 013 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 012 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 011 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

We can see our “Future Technology, Ltd Bridge”, as seen on the server side, it seems perfect.

b. Starting the whole thing at boot with systemd

Here again we will use a new systemd unit file (/etc/systemd/system/usbip.service) to monitor & mount the remote electrical sensor over IP.

root@DEBIAN10-3-JEEDOM:~# joe /etc/systemd/system/usbip.service

[Unit]
Description=Connects remote USB device over IP
Requires=systemd-networkd-wait-online.service
After=systemd-networkd-wait-online.service

[Service]
Type=simple
Restart=on-failure
User=root
Group=root
ExecStart=/usr/local/sbin/usbip_teleinfo.sh

[Install]
WantedBy=multi-user.target

This unit will launch a script (/usr/local/sbin/usbip_teleinfo.sh) with a loop checking regularly if the specified endpoints are mounted or not, and if not, try to mount them. It also traps the various Unix termination signals to properly unbind the mounted remote devices. You have to replace the SERVER IP and the BUS ID exposed on SERVER that you want to mount.

root@DEBIAN10-3-JEEDOM:~# joe /usr/local/sbin/usbip_teleinfo.sh

#!/bin/bash

ENDLESS=true
LANG=C
SERVER='192.168.1.46'
BUSID='1-1.5'

trap_exit() {
    ENDLESS=false
    for PORT in $(/usr/sbin/usbip port | /usr/bin/grep ^Port | /usr/bin/cut -d':' -f1 | /usr/bin/awk '{print$2}'); do
        /usr/sbin/usbip detach -p $PORT
    done
    exit 0
}

trap trap_exit SIGINT
trap trap_exit SIGTERM
trap trap_exit SIGKILL

while $ENDLESS; do
    if ! /usr/sbin/usbip port | /usr/bin/grep "usbip:.*${SERVER}.*${BUSID}$" &> /dev/null; then
        /usr/sbin/usbip attach -r ${SERVER} -b ${BUSID}
    fi
    sleep 30
done

trap_exit

root@DEBIAN10-3-JEEDOM:~# chmod 0750 /usr/local/sbin/usbip_teleinfo.sh

Once again, we need to make sure the systemd unit on which we have a dependency to know if the network is UP or not, is enabled on the system.

root@DEBIAN10-3-JEEDOM:~# systemctl enable systemd-networkd-wait-online.service

Then we ask systemd to enable our new unit file at startup.

root@DEBIAN10-3-JEEDOM:~# systemctl daemon-reload
root@DEBIAN10-3-JEEDOM:~# systemctl enable usbip.service
Created symlink /etc/systemd/system/multi-user.target.wants/usbip.service → /etc/systemd/system/usbip.service.

And we test it …

root@DEBIAN10-3-JEEDOM:~# sudo systemctl start usbip.service

This time no error. This is normal as to write this article and add the scripts above, I had to unplug my raspberry so the mounted point disappeared on my Jeedom controller. Let’s test the USB peripherals attached on the Jeedom box.

root@DEBIAN10-3-JEEDOM:~# lsusb
Bus 018 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 017 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 016 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 015 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 014 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 013 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 012 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 011 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@DEBIAN10-3-JEEDOM:~#

The “Future Technology Devices International, Ltd Bridge” is locally present, this is perfect. Now, we have a system which will automagically mount the remote electrical sensor on the Jeedom controller, after a reboot either on the remote raspberry, or on the jeedom controller.

Beware, for this to work, your raspberry absolutely need a static IP address ! You need either to fix this ip address on the raspberry (and not use DHCP), OR use a static DHCP lease on your DHCP server or router/internet box.

3. Monitoring power consumption in Jeedom

Now we need to install a power consumption dedicated plugin in jeedom: I choosed the “Teleinfo” plugin which is free. Go in Jeedom’s plugins page, then on the Market, and look for “Teleinfo”. Click on the button to install it, once it’s done Jeedom will ask you to go on its configuration page, click Yes.

The screenshot below will not be the exact same thing you will have just after the plugin installation, as I already configured it. Basically what you will have to do after a fresh plugin installation is:

1. (red circle below) Launch the dependencies compilation
2. (purple circle below) I strongly suggest to start with logs in DEBUG mode, to check there are not errors in any logs (then you will fallback the logs in INFO mode), and SAVE
3. (blue circle below) Select the electrical modem in the Modem 1 dropdown list, as you can see in my case it is mounted en /dev/ttyUSB0, SAVE again
4. (green circle below) Wait for the daemon to restart, it should go green. If it doesn’t after a few minutes, carefully check the logs.

I will also activate the Desktop panel view, at the bottom of the configuration page (green circle below). SAVE again.

You can also have a look at the “Diagnostic” button (in blue above), it will perform step by step a few confirmations about your setup and the remote sensor.

Now, go in the main Teleinfo plugin page.

A new object was automatically added, because as soon as the Teleinfo daemon started, it started to collect some data from the remote electrical sensor/modem. The plugin was therefore able to deduct some information about your electrical meter, including its identifier. If you click on it you will see more things.

1st thing I suggest here is to enable the commands creation (green circle above). Enabling this will tell the plugin to create new commands when it will receive new fields it never saw before, in the data it receives from the sensor.

2nd thing I recommend is to check the health of the data (orange circle above).

In this view you can see the fields already received from your electrical sensor, and when were the last update for each. Now let’s have a look on the automatically created commands, for this Jeedom’s object.

All those commands are the fields received through the electrical sensor’s data, converted into Jeedom’s individual information fields you can now display, store, and use in various processings you may want to add.

In my case I don’t want to track every data over timeso let’s uncheck a few things.

Now if we display the Jeedom’s homepage, we can see the Teleinfo widget.

Next, I will focus on the real time power consumption (IINST & PAPP – Intensité Instantanée & Puissance Apparente in French). Electricity consumption is billed on the basis of the Watts delivered by your installation. The PAPP value is not in Watts, but in Volts.Amps (V.A). We could think 1 V.A = 1W because we learned at school that P=U.I …. But this is mostly true for D.C (Direct current), not A.C (Alternating current) ! With A.C, P must be used with U, I and a cos.phi ratio: P = U x I x cos φ. The cos φ is usually specific to each electrical equipment and written on it, but the most important is that it’s not always the same depending on the type of equipement ! Therefore, we can not base an accurate electrical consumption on the PAPP.

But, we have the instantaneous intensity delivered, (IINST, Amps). In France, the electric tension can vary between 220v and 240v depending how far you are from the electric transformer. We can obtain a medium live consumption in Watts with IINST * 230v.

So, lets create a new informational command inside our electric meter in Jeedom.

With a few more tuning, by using different data provided by the plugin’s commands, and by modifying the design of the widget, I obtain this simple widget:

A few explanations about this widget: I used some of the commands provided by the plugin, and i tweaked a little bit the widget from Jeedom’s Dashboard (by using Jeedom’s Widget edition mode).

• First line displays the type of my subscription (here: TEMPO from EDF (Electricité de France)), actual daily rate (here: HP BLEU), instant power delivered (here: 1191 Watts)
• Second line is only cosmetic: i couldn’t use <BR> HTML tags to add an empty line, so i added three “-“
• Third line explains the two columns of the array below: today, and yesterday
• 4th, 5th and 5th lines are used for the cumulated costs, and consumption for today and yesterday.

But, the most important data is provided by the Teleinfo plugin’s own dashboard.

Different kind of statistics will be displayed … Depending on your type of subscription to the provider.

It is important to explain here that i’m only a “consumer” of electricity, not a producer; but, in France, if you produce electricity too (even small solar panels, etc.), you can inject your production on the main network, and be rewarded for that. If I was ap roducer, and if I choosed to “sell” my production, it would also be seen in the statistics below.

Conclusion

We have seen how to implement a highly accurate system for monitoring and logging electricity consumption (for a French electricity meter), using the “USB over IP” technique, so that a USB modem connected to my electricity meter and to a Raspberry Pi can be used, with the Raspberry Pi communicating via Wi-Fi with the central Jeedom home automation controller located about fifteen meters away (with no simple or discreet wiring possible between the two).

Thanks !