Home Automation Domotica Forum Europe, Bwired Forum

I've decompiled the hdrv_p1 binary, and I came across the following
The name of the function suggest that Toon checks with Quby/Eneco if the reported meter (with it's serial number) is a smart meter (mine is not, otherwhise this project didn't exist)
I'll try to do a man in the middle attack on my Toon to verify this

timkoers wrote: Could you send me the build environment you have for building packages for the Toon?
Thanks!

That's a tall order. The oe development tree has grown to a size of 30-odd GB. That's not easily transferred.

marcelr wrote: That's a tall order. The oe development tree has grown to a size of 30-odd GB. That's not easily transferred.

Yes I'm sorry!
I think the key to solving this problem is to pause the execution of the program and look at it's buffers, so that's why the gdb comes in handy.

Could you build it for me?

I think it's been built three to four years ago . Will put it on the ftp server later today. You may also want strace and tcpdump, I guess?

marcelr wrote:I think it's been built three to four years ago . Will put it on the ftp server later today. You may also want strace and tcpdump, I guess?

That would be really nice, whilest you're at it!

It should be all there. Same spot as last time, deps should be complete as well.

marcelr wrote:It should be all there. Same spot as last time, deps should be complete as well.

Hero!

I'll try to give it a try tomorrow!

marcelr wrote:It should be all there. Same spot as last time, deps should be complete as well.

During the installation it shows gdb: unsatisfied recommendation for glibc-thread-db, but it installs and works.

Could you build gdbserver? With that one I can debug the hdrv_p1 code remotely.

timkoers wrote: Could you build gdbserver? With that one I can debug the hdrv_p1 code remotely.

It's inside the oe-tree, will give it a shot.

marcelr wrote:

timkoers wrote: Could you build gdbserver? With that one I can debug the hdrv_p1 code remotely.

It's inside the oe-tree, will give it a shot.

Thanks!

According to TheHogNL, in /qmf/etc/qmf_release.xml there is a <uartcheck> enabled section under the hdrv_p1. Not sure what it does but maybe that is causing your issue.

I've turned off the uartcheck and I do get loads of ACTION_RESPONSES instead of only ACTION_INVOKES. Still no data. The Toon crashes regularly when (wrong) data is being fed into the P1 port.

Done, available from the usual location.

I think I've overseen a very important note.

Logical levels are specified as follows:
SPACE “0” usually > 4V
MARK “1” as < 1 V

Meaning, the levels are inverted. Right?

I'll try to add an inverter since I've not got any useful data out of my two day debugging session, other than that the hdrv_zwave decides if the meter report is unsolicited or not.

Also there seems to be some kind of table with meter information, and if you leave the CRC out of the telegram, it looks like the table gets resetted or something

Right. And port settings were a bit exotic as well : 7E1, instead of the usual 8N1.

DSMR 3 was 7E1, DSMR 4 and 5 use the normal 8N1.

timkoers wrote:Meaning, the levels are inverted. Right?

Correct. I was wondering before why you are messing with level shifters. The specs indicate that the interface may be accomplished by opto-couplers. So, that's what I would have done: Just attach the serial output of a Raspberry Pi or Arduino to an opto-coupler and you should be all set. That way you also avoid any issues with grounds being tied together. Unfortunately I didn't have time to check myself if that would work. I still don't.