hi im getting this error

[Mark-C-uk]

Traceback (most recent call last): File "monitor.py", line 210, in monitor() File "monitor.py", line 182, in monitor if decoded["recs"][0]["paramid"] == OpenHEMS.PARAM_JOIN: IndexError: list index out of range

[Mark-C-uk]

i had started to try and add eTRV's to the code

[whaleygeek]

Hi Mark,

This error occurs when an Energenie device sends back a message with no payloads in it, which does happen from time to time. You should modify the line of code to say this

if len(decoded["recs"]) > 0 and decoded["recs"][0]["paramid"] == OpenHEMS.PARAM.JOIN:

That will fix the problem. I'll leave this issue open and implement a proper fix soon.

Also, Ed has send a pull request for his eTRV code, if you can 'see' that pull request yourself, you could just take on his code and use that, as it is known to work. I hope to merge this and regression test it sometime over the Christmas break, as I now have an eTRV on loan from Energenie in order to test this myself.

[Mark-C-uk]

this might (will) sound stupid, how do i make his changes? just follow each step in the pull request or just make the changes detailed in the last?

I am very new to this have done some vba work in excel making a gui for spreadsheets etc. i have bought some etrv's, some basic sockets, the rf board and a new pi to learn, nothing worked and engenie have said the broadcom is compatible with the new pi and have pointed me at your github page. thanks

On 18 December 2015 at 20:42, David Whale notifications@github.com wrote:

Hi Mark,

This error occurs when an Energenie device sends back a message with no payloads in it, which does happen from time to time. You should modify the line of code to say this

if len(decoded["recs"]) > 0 and decoded["recs"][0]["paramid"] == OpenHEMS.PARAM.JOIN:

That will fix the problem. I'll leave this issue open and implement a proper fix soon.

Also, Ed has send a pull request for his eTRV code, if you can 'see' that pull request yourself, you could just take on his code and use that, as it is known to work. I hope to merge this and regression test it sometime over the Christmas break, as I now have an eTRV on loan from Energenie in order to test this myself.

— Reply to this email directly or view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/19#issuecomment-165893743 .

[whaleygeek]

Your quickest way in might be to DownloadZip from Ed's fork over here, as it will be a few days before I can merge the pull request onto my site.

https://github.com/cafebabe/pyenergenie

The older (green button) sockets are not supported (yet) by my code, I will add those soon, but getting the eTRV merged in will be my next task. I wrote the code initially to enable using the MiHome Adaptor Plus from Python, legacy devices will be added later.

In fact, you could fork from here https://github.com/cafebabe/pyenergenie and then DownloadZip from the button on your own github site. You then have your own copy of code that you can modify to suit your own needs, and that way, as myself and Ed add new features, you can choose whether to accept those as and when it makes sense for you.

If you discover things and improve the code yourself, you can then contribute those improvements back to us to merge into the mainline code.

Hope this helps!

[whaleygeek]

Also, if you have a Pi 2, you need to make sure you have either updated your OS (as per instructions on RaspberryPi.org) OR got the latest OS - there were changes in the OS and in the RPi.GPIO module when the Pi2 came out that broke a few things, and you need a recently updated OS for the GPIO to work correctly. This might not be an issue for you, if you have a recent OS on your Pi anyway.

[Mark-C-uk]

Thanks for that the first thing i tryed was updating. I did have a kernel warning on start. The long term plan is to get a touch screen for the pi and to be able control everything from that internally. Getting it to call the boiler on say when the trv's are > 1 oC of the set value. On 19 Dec 2015 16:29, "David Whale" notifications@github.com wrote:

Also, if you have a Pi 2, you need to make sure you have either updated your OS (as per instructions on RaspberryPi.org) OR got the latest OS - there were changes in the OS and in the RPi.GPIO module when the Pi2 came out that broke a few things, and you need a recently updated OS for the GPIO to work correctly. This might not be an issue for you, if you have a recent OS on your Pi anyway.

— Reply to this email directly or view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/19#issuecomment-166001557 .

[Mark-C-uk]

ed's is working fine but when i get the 'cant decode payload bad crc' i noted in the info a 0x73 which i thought was for switch state i do have 3 home adaptors (https://energenie4u.co.uk/catalogue/product/MIHO002) and wonder if it was them reporting?

[0x2a,0x9c,0xd3,0xaa,0x53,0xca,0x59,0xfa,0x33,0xb3,0xba,0x9e,0xbc,0x8d,0x98,0xde,0x87,0xd0,0x55,0xfc,0xbc,0x41,0x8,0xd0,0xee,0x43,0xb3,0xec,0xe6,0xb6,0x56,0x35,0x7a,0xab,0xbd,0x3f,0xf0,0x96,0xec,0xbb,0xff,0xab,0x21] 0x2a 0x9c 0xd3 0xaa 0x53 0xf7 0x9a 0xbf 0xa1 0x88 0xe2 0x15 0x84 0x9d 0x36 0xa4 0xd4 0xfc 0x2 0x52 0x46 0x1e 0x59 0x8d 0xf6 0xb2 0x73 0x19 0x8c 0xf8 0xb 0x4d 0x98 0xce 0xfe 0xae 0xfb 0x2 0x94 0xf1 0x80 0x53 0x27 Can't decode payload:'bad CRC' receiving payload

On 19 December 2015 at 16:27, David Whale notifications@github.com wrote:

Your quickest way in might be to DownloadZip from Ed's fork over here, as it will be a few days before I can merge the pull request onto my site.

https://github.com/cafebabe/pyenergenie

The older (green button) sockets are not supported (yet) by my code, I will add those soon, but getting the eTRV merged in will be my next task. I wrote the code initially to enable using the MiHome Adaptor Plus from Python, legacy devices will be added later.

In fact, you could fork from here https://github.com/cafebabe/pyenergenie and then DownloadZip from the button on your own github site. You then have your own copy of code that you can modify to suit your own needs, and that way, as myself and Ed add new features, you can choose whether to accept those as and when it makes sense for you.

If you discover things and improve the code yourself, you can then contribute those improvements back to us to merge into the mainline code.

Hope this helps!

— Reply to this email directly or view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/19#issuecomment-166001481 .

[whaleygeek]

Ed did discover something in the vicinity of his house that was blurting out CRC failing messages, maybe a non-energenie device from a neighbour. You might try turning off ALL of your energenie devices, and see if you still get the badCRC messages to prove this.

[whaleygeek]

Also, if all your adaptors try to transmit at the same time, you'll get a collision on the network and this will cause a bad CRC. I haven't been able to find out from Energenie yet whether the adaptors insert a random startup delay on power cycle (the use case being a whole-house mains failure, that with a fixed init time would cause all devices to report at precisely the same time, and no messages would get through). The OpenHEMS (OpenThings) protocol doesn't have any collision avoidance, so the performance of any system is limited by the specific manufacturer design decisions made.

I would turn off all devices and this would help prove if you have any other non Energenie devices nearby that are blurting out data.

[whaleygeek]

This is now fixed in this commit:

https://github.com/whaleygeek/pyenergenie/commit/7fcf416e2d786b3c78629cef6e11df5ef4b9a785

Additionally, If you get 'bad CRC' errors, it is either a non Energenie device transmitting, or an Energenie device that is out of range, which causes the payload to become corrupted. Mostly you should ignore these messages, they were only there for debugging the initial code. I plan to add diagnostic messages to a disk file log in the future, rather than displaying them on the screen.