PellMon på Raspberry

[motoz]

With the new 0.6.1 release PellMon is now super-easy to install, check out https://github.com/motoz/PellMon/wiki/How-to-install-PellMon

And for those who are already running a version older than 0.6.1, here are the new upgrade instructions: https://github.com/motoz/PellMon/wiki/How-to-upgrade-PellMon

[khe]

Looking forward to try it out!

Thank You, for still developing 

[motoz]

The new PellMon plugin for V7/V13 controllers is starting to become usable.



Stokercloud and the official android app can of course be used in parallel.

The PellMon plugin requires controller version 7.0636 or newer (or the matching V13 version). The only configuration required for the plugin to work is to add the controller serial number and password in the configuration file:

Kode: [Vælg]

[plugin_NBEcom]
serial = 01012
password = 0123456789And for those that like me have been using PellMon with an old controller for a while, the complete history ie. graphs, events and consumption charts will be kept when changing the controller to a V7, just switch the scottecom plugin to the new nbecom, and adjust configuration for the data written to the database. (Not released yet but the source code is available on github in the 'feature/nbecontrol' branch)

[motoz]

Beta 1 release of PellMon version 0.7.0:
https://github.com/motoz/PellMon/releases

One of the highlights is of course the new NBEcom plugin for V7/V13 controllers. Installing is as simple as downloading the file and running:

Kode: [Vælg]

sudo gdebi pellmon_0.7.0.beta1-1_all.debUpgrading from 0.6.1 is just as easy. The installation might pause and ask what to do with a configuration file that has been changed, just press enter to confirm that you want to keep your own modifications.

To be able to use the new NBEcom plugin a new dependency 'xtea' is needed that unfortunately is not available in the debian repository. It can be installed with pip:

Kode: [Vælg]

sudo pip install xtea

[motoz]

The V7 vcontroller is doing watchdog resets every now and then while using the UDP protocol, so I can't recommend using the NBEcom plugin with a 'live' burner yet. The problem is still there on the latest V7 version 7.0638. I could probably paper over the controller bug by slowing down the communication, but that probably only makes watchdog resets occur more seldom.

[BoinkUser]

The V7 vcontroller is doing watchdog resets every now and then while using the UDP protocol, so I can't recommend using the NBEcom plugin with a 'live' burner yet. The problem is still there on the latest V7 version 7.0638. I could probably paper over the controller bug by slowing down the communication, but that probably only makes watchdog resets occur more seldom.

Hi Motoz

Looks good

Can you somehow isolate the reset problem? We do not see any resets here, but you might send request in another way/order/timing, i will be happy to solve it.

Regards Jens

[motoz]

Don't really have any time to spare for this project now (summer and all), but it's running nonstop so I try to keep an eye on the logs. There is a watchdog powerup maybe once or twice a week but I have not tried to look into what message sequence leads to it.

The pellmon plugin renews the xtea key quite aggressively (probably excessively so) and if there is any problem with setting the new xtea key (eg. timeout) it gives up immediately and switches to rsa for writing settings, because then it's not known if the controller uses the new or the old xtea key so it's simpler to handle it that way. The next xtea key renewal will then use rsa encryption, and I I have a feeling that it might be the rsa decryption on the controller that can cause a watchdog reset.

You could try latest pellmon beta and see if you get the same behaviour, or with my test client something like:

Kode: [Vælg]

watch -n 5 ./client.py -p 1234567890 set settings/boiler/temp 60to provoke it by causing an rsa decryption every 5 second

[BoinkUser]

Don't really have any time to spare for this project now (summer and all), but it's running nonstop so I try to keep an eye on the logs. There is a watchdog powerup maybe once or twice a week but I have not tried to look into what message sequence leads to it.

The pellmon plugin renews the xtea key quite aggressively (probably excessively so) and if there is any problem with setting the new xtea key (eg. timeout) it gives up immediately and switches to rsa for writing settings, because then it's not known if the controller uses the new or the old xtea key so it's simpler to handle it that way. The next xtea key renewal will then use rsa encryption, and I I have a feeling that it might be the rsa decryption on the controller that can cause a watchdog reset.

You could try latest pellmon beta and see if you get the same behaviour, or with my test client something like:

Kode: [Vælg]

watch -n 5 ./client.py -p 1234567890 set settings/boiler/temp 60to provoke it by causing an rsa decryption every 5 second

Hi Motoz

I will try that out and see what happens.

Regards Jens

[motoz]

Fwiw, here's a log with pellmon+nbecom plugin and the nbetest client writing to settings/boiler/temp every 5 second:

2016-06-22 12:00:20,872 - INFO - "Auger feed time at 10%" changed from 1.75% to 0.34%
2016-06-22 12:00:10,588 - INFO - type: 2, id: 3, v1: 13, v2: 638
2016-06-22 12:00:10,588 - INFO - "Auger feed time at 10%" changed from 0.34% to 1.75%
2016-06-22 12:00:05,198 - INFO - Reconnected to controller on 192.168.1.123
2016-06-22 11:59:59,974 - INFO - Lost connection to controller
2016-06-22 11:59:30,623 - INFO - "Auger feed time at 10%" changed from 1.75% to 0.34%
2016-06-22 11:59:15,305 - INFO - type: 2, id: 3, v1: 13, v2: 638
2016-06-22 11:59:15,305 - INFO - "Auger feed time at 10%" changed from 0.34% to 1.75%
2016-06-22 11:56:01,647 - INFO - "Auger feed time at 10%" changed from 1.75% to 0.34%
2016-06-22 11:55:43,700 - INFO - Reconnected to controller on 192.168.1.123
2016-06-22 11:55:43,552 - INFO - type: 2, id: 3, v1: 13, v2: 638
2016-06-22 11:55:43,552 - INFO - "Auger feed time at 10%" changed from 0.34% to 1.75%
2016-06-22 11:55:38,940 - INFO - Lost connection to controller
2016-06-22 11:25:13,561 - INFO - "Auger feed time at 10%" changed from 1.75% to 0.34%
2016-06-22 11:24:55,200 - INFO - type: 2, id: 3, v1: 13, v2: 638
2016-06-22 11:24:55,197 - INFO - "Auger feed time at 10%" changed from 0.34% to 1.75%
2016-06-22 11:24:52,949 - INFO - Reconnected to controller on 192.168.1.123
2016-06-22 11:24:38,890 - INFO - Lost connection to controller
2016-06-22 11:07:38,053 - INFO - "Wanted boiler temp." changed from 58C to 61C
2016-06-22 08:57:11,531 - INFO - Connected to S/N 23015 on 192.168.1.123
2016-06-22 08:57:10,529 - INFO - Activated plugins: SiloLevel, Consumption, Cleaning, NBEcom
2016-06-22 08:57:10,493 - INFO - starting pelletMonitor

Four watchdog resets in about half an hour.

[motoz]

I will try that out and see what happens.

Do you see the watchdog resets or not?

[motoz]

This python snippet resets my burner immediately, probably any other burner in the network also:

Kode: [Vælg]

import socket

m = [32, 32, 99, 106, 104, 101, 107, 97, 101, 106, 38, 101, 100, 106, 103, 104, 104, 106, 42, 255, 83, 26, 1, 238, 107, 82, 196, 213, 205, 220, 226, 207, 93, 175, 27, 245, 207, 100, 255, 42, 27, 176, 53, 171, 161, 12, 55, 124, 67, 112, 4, 25, 234, 125, 236, 101, 3, 228, 126, 53, 147, 92, 65, 82, 152, 253, 237, 106, 197, 18, 183, 56, 150, 9, 147, 193, 53, 20, 35, 63, 173, 34]

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)

s.sendto(''.join([chr(int(c)) for c in m]) , ('<broadcast>', 8483))


[motoz]

The bug in the controller seems to be that any rsa chiphertext shorter than 64 bytes locks up the controller and cause a watchdog reset.

When encrypting the frame I sometimes (depending on the plaintext contents, for instance the included timestamp varies) get only 63 bytes chiphertext, which then causes the reset. The too short chiphertext appears to be completely valid, I get the same behaviour with a key I generated myself and then the 63 byte chiphertext decrypts correctly. I wonder if this is possibly caused by the protocol using 'plain RSA' without applying any standard padding scheme like PKCS or OAEP. This comment here: http://stackoverflow.com/questions/25699187/rsa-encryption-output-size

Being somewhat pedantic I could argue that if the modulus is small for its bit size (say it begins with the bits 100) then you have a fair chance to get a ciphertext that is actually a bit shorter than the the modulus.

seems to support that the behaviour is expected and not a bug in the python library.

Anyway, I can avoid the issue by simply adding a different random padding and encrypting again when the message is too short. By doing this there are no watchdog resets, even when abused by the 5s 'watch' script in parallel with pellmon.

[BoinkUser]

The bug in the controller seems to be that any rsa chiphertext shorter than 64 bytes locks up the controller and cause a watchdog reset.

When encrypting the frame I sometimes (depending on the plaintext contents, for instance the included timestamp varies) get only 63 bytes chiphertext, which then causes the reset. The too short chiphertext appears to be completely valid, I get the same behaviour with a key I generated myself and then the 63 byte chiphertext decrypts correctly. I wonder if this is possibly caused by the protocol using 'plain RSA' without applying any standard padding scheme like PKCS or OAEP. This comment here: http://stackoverflow.com/questions/25699187/rsa-encryption-output-size

Being somewhat pedantic I could argue that if the modulus is small for its bit size (say it begins with the bits 100) then you have a fair chance to get a ciphertext that is actually a bit shorter than the the modulus.

seems to support that the behaviour is expected and not a bug in the python library.

Anyway, I can avoid the issue by simply adding a different random padding and encrypting again when the message is too short. By doing this there are no watchdog resets, even when abused by the 5s 'watch' script in parallel with pellmon.

Hej Motoz

Thats great, we will look into this issue, we could at least reject the package with a invalid message code when this happens.

Thank you.

Regards Jens

[motoz]

Beta2 for release 0.7.0 published: https://github.com/motoz/PellMon/releases

The V7/13 support is now completely stable and usable (no known bugs, but the parameter menus could be more user friendly).

Installation howto: https://github.com/motoz/PellMon/wiki/How-to-install-PellMon

Dowload the beta2 .deb file with:

Kode: [Vælg]

wget https://github.com/motoz/PellMon/releases/download/v0.7.0-beta2/pellmon_0.7.0.beta2-1_all.deb
And remeber to install the additional dependency xtea if you are going to use PellMon with a V7/13 controller:

Kode: [Vælg]

sudo apt-get install python-pip
sudo pip install xtea
Since PellMon by default logs data from the scottecom plugin (V4/5/6 burners) you need to make some changes to the configuration to work with a V7/13, first the scottecom plugin should be disabled and NBEcom enabled:
/etc/pellmon/conf.d/enabled_plugins.conf:

Kode: [Vælg]

#p01 = ScotteCom
p12 = NBEcom
Then you need to add some data to be fed into the database in the file /etc/pellmon/conf.d/database.conf
Anything available in the parameters page can be logged and graphed by changing that file.

There is no system image with data from the NBEcom plugin included yet but you can of course make your own.

Have fun.

[khe]

Hi Motoz!

Hope you are enjoying summertime 

I'm preparing for next season, and decided to update my Pi to Weezy and Pellmon 0.6.1, and got it all up and running, except from the database with consumption log - is it possible to transfer it to the new version?

I have copied  RRD database from the old install: /usr/local/var/lib/pellmon/rrd.db to the new install: /var/lib/pellmon/rrd.db - do I miss some point of config setup or so, to get it to work?

I have followed the description in your Wiki here: https://github.com/motoz/PellMon/wiki/Backup-or-Move-PellMon

Thanks in advance - Kristian.