[WIP/Released] P1 Data injector

Everything about software tools, new software development and toolchains. For developers, mostly.

Moderators: marcelr, TheHogNL, Toonz

timkoers
Member
Member
Posts: 77
Joined: Thu Jun 28, 2018 6:43 pm

[WIP/Released] P1 Data injector

Post by timkoers »

Important notice!
Please do not use this piece of software to fake your energy bills. I am not responsible for any kind of damage you may get whilest using this piece of software.



The source code, complete with schematics for this project is now available! View my GitLab
https://gitlab.com/timkoers/p1-simulator

Please change the serial number (field 0:96.1.1) to the hexadecimal ascii representation of your own serial number

There are a few things that I need your help for however:
  • * The current power usage is not stable, it fluctuates very much
    * I've got my doubts about the validity of the 1.7.0, 2.7.0 and the instantaneous active power import/exports
To debug the code, change the debug flag from

Code: Select all

False
to

Code: Select all

True
Original post:

Recently I started a project to inject P1 data onto the 'MeterAdapter's' P1 bus. I was already collecting data from my not so smart, smart meter by using an IR head.
I parsed the data and converted into a hopefully valid P1 signal.

This is the telegram that I am trying to sent:

Code: Select all

/ISk5MT174-001
1-3:0.2.8(50)
1-0:1.8.1(2421.327*kWh)
1-0:1.8.2(1868.510*kWh)
1-0:2.8.1(150.503*kWh)
1-0:2.8.2(487.218*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(0.000000*kW)
1-0:2.7.0(0.000000*kW)
0-0:96.7.21(00000)
0-0:96.7.9(00000)
1-0:99.97.0(0)(0-0:96.7.19)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.0(0)
1-0:32.7.0(227.7*V)
1-0:52.7.0(231.5*V)
1-0:72.7.0(232.7*V)
1-0:31.7.0(0.43*A)
1-0:51.7.0(6.24*A)
1-0:71.7.0(5.84*A)
!
I provided a DSMR version of 50, to hopefully trick the Toon into using the DSMR 5.0 standard. The whole message, including an CRC looks like this (with the required \r\n at each line):

Code: Select all

/ISk5MT174-001
1-3:0.2.8(50)
1-0:1.8.1(2421.327*kWh)
1-0:1.8.2(1868.510*kWh)
1-0:2.8.1(150.503*kWh)
1-0:2.8.2(487.218*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(0.000000*kW)
1-0:2.7.0(0.000000*kW)
0-0:96.7.21(00000)
0-0:96.7.9(00000)
1-0:99.97.0(0)(0-0:96.7.19)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.0(0)
1-0:32.7.0(227.7*V)
1-0:52.7.0(231.5*V)
1-0:72.7.0(232.7*V)
1-0:31.7.0(0.43*A)
1-0:51.7.0(6.24*A)
1-0:71.7.0(5.84*A)
!7BF6
Before sending any data, my Toon detect's that there is a smart meter at the other end of the P1 cable, which is great, but when I send data when the RTS line tells me to, the Toon stops to detect the smart meter.
When I stop the script that send the test telegram message, my Toon detects the smart meter right away.

I am not sure what is the problem of that issue, but I'd like to dive into some logs. How is the data from the 'MeterAdapter' being send to the Toon? Is that raw P1 data, or is it parsed data?
Last edited by timkoers on Mon Sep 24, 2018 8:47 am, edited 6 times in total.
marcelr
Global Moderator
Global Moderator
Posts: 1153
Joined: Thu May 10, 2012 10:58 pm
Location: Ehv

Re: P1 Data injector

Post by marcelr »

Hi timkoers,

Nice feature!

I'm not very well versed in DSMR 5.0, but I think that besides the meter type also the meter serial number is transferred, in decimal ASCII representation of the digits ( 0 -> 30, 1-> 31, etc.). Not sure if that's required in DSMR 5.0, my Kamstrup meter spits out this info in every packet.

Packets are sent every 10 seconds, when RTS is pulled high.

The meteradapter sends data to toon through the z-wave interface and protocol. Good luck with sniffing those actual packets. You might try to intercept the data from the z-wave interface of toon, which are transferred to the processor through a serial interface. It's fairly straightforward to intercept these, but a bit more cumbersome to find out what exactly the data are. The z-wave protocol has quite some overhead in its packets.
I have built the openzwave lib for toon some time ago, together with a webinterface (ozwcp, hosted on another computer) to control it. It also logs all zwave traffic. Data are similar to the serial IO data, but logging is less of a hassle, and more or less sorted along network IDs in the zwave network. Maybe that's of use to you. If so, just yell.
hvxl
Senior Member
Senior Member
Posts: 1987
Joined: Sat Jun 05, 2010 11:59 am
Contact:

Re: P1 Data injector

Post by hvxl »

A few remarks, not sure which ones are relevant to your issue:
  • There is supposed to be an empty line after the ident line (specs say: /XXXZ Ident CR LF CR LF Data ! CRC CR LF, i.e.: double CR LF after Ident).
  • The CRC value in the message you posted is incorrect. As posted, the CRC is 78F8.
  • DSMR 5.0 calls for a packet every second, not every 10 seconds.
Schelte
timkoers
Member
Member
Posts: 77
Joined: Thu Jun 28, 2018 6:43 pm

Re: P1 Data injector

Post by timkoers »

marcelr wrote:Hi timkoers,

Nice feature!

I'm not very well versed in DSMR 5.0, but I think that besides the meter type also the meter serial number is transferred, in decimal ASCII representation of the digits ( 0 -> 30, 1-> 31, etc.). Not sure if that's required in DSMR 5.0, my Kamstrup meter spits out this info in every packet.

Packets are sent every 10 seconds, when RTS is pulled high.

The meteradapter sends data to toon through the z-wave interface and protocol. Good luck with sniffing those actual packets. You might try to intercept the data from the z-wave interface of toon, which are transferred to the processor through a serial interface. It's fairly straightforward to intercept these, but a bit more cumbersome to find out what exactly the data are. The z-wave protocol has quite some overhead in its packets.
I have built the openzwave lib for toon some time ago, together with a webinterface (ozwcp, hosted on another computer) to control it. It also logs all zwave traffic. Data are similar to the serial IO data, but logging is less of a hassle, and more or less sorted along network IDs in the zwave network. Maybe that's of use to you. If so, just yell.
That lib is really useful! I suppose I can find it in the downloads section of this folder?
The serial info is there in the actual code, I just removed it to make the CRC correct for the post. Which, was wrong unfortunately.
hvxl wrote:A few remarks, not sure which ones are relevant to your issue:
  • There is supposed to be an empty line after the ident line (specs say: /XXXZ Ident CR LF CR LF Data ! CRC CR LF, i.e.: double CR LF after Ident).
  • The CRC value in the message you posted is incorrect. As posted, the CRC is 78F8.
  • DSMR 5.0 calls for a packet every second, not every 10 seconds.
So this should be the right format now (which excludes the serial ofcourse):

Code: Select all

/ISk5\MT174-001

1-3:0.2.8(50)
1-0:1.8.1(2421.327*kWh)
1-0:1.8.2(1868.510*kWh)
1-0:2.8.1(150.503*kWh)
1-0:2.8.2(487.218*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(0.000000*kW)
1-0:2.7.0(0.000000*kW)
0-0:96.7.21(00000)
0-0:96.7.9(00000)
1-0:99.97.0(0)(0-0:96.7.19)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.0(0)
1-0:32.7.0(227.7*V)
1-0:52.7.0(231.5*V)
1-0:72.7.0(232.7*V)
1-0:31.7.0(0.43*A)
1-0:51.7.0(6.24*A)
1-0:71.7.0(5.84*A)
!
How did you calculate the CRC? I had no way of checking if the CRC was right and turns out it wasn't :P
When I removed the time.sleep(10) in my Python script, I did see data being transfered every second. Which maked the Toon think that there was no smart meter attached, probably because it wasn't able to identify it correctly.
timkoers
Member
Member
Posts: 77
Joined: Thu Jun 28, 2018 6:43 pm

Re: P1 Data injector

Post by timkoers »

I've updated the code a little and it now generates the following telegram

Code: Select all

/ISk5\MT174-001

1-3:0.2.8(50)
0-0:1.0.0(180804122151W)
1-0:1.8.1(0000.000*kWh)
1-0:1.8.2(0000.000*kWh)
1-0:2.8.1(0000.000*kWh)
1-0:2.8.2(0000.000*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(0000.000*kW)
1-0:2.7.0(0000.000*kW)
0-0:96.7.21(00000)
0-0:96.7.9(00000)
1-0:99.97.0(0)(0-0:96.7.19)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.0(0)
1-0:32.7.0(000.0*V)
1-0:52.7.0(000.0*V)
1-0:72.7.0(000.0*V)
1-0:31.7.0(000.0*A)
1-0:51.7.0(000.0*A)
1-0:71.7.0(000.0*A)
!02AD
According to scadacore.com/tools/programming-calcula ... alculator/, the checksum is correct :)
Again the serial number is included in the Telegram, but is excluded in the CRC of the Telegram above.

When trying to send data, the Toon has crashed a total of 3 or 4 times today. So it's definitely receiving some data, but not the correct data.
TheHogNL
Forum Moderator
Forum Moderator
Posts: 2125
Joined: Sun Aug 20, 2017 8:53 pm

Re: P1 Data injector

Post by TheHogNL »

Try to debug on your toon by running the app which is collection the p1 data with:

/qmf/sbin/hdrv_p1 -vvvv
Member of the Toon Software Collective
marcelr
Global Moderator
Global Moderator
Posts: 1153
Joined: Thu May 10, 2012 10:58 pm
Location: Ehv

Re: P1 Data injector

Post by marcelr »

I think that TheHogNL's suggestion is a very good one. By killing hdrv_p1 and starting it again with the -vvv option, you should see what's going on.

Nevertheless, I uploaded the openzwave package, ozwcp (controlpanel, to be installed on toon, and then to be commanded from a web browser), plus a few deps (udev, udev-utils, libmicrohttpd) to the file server. Need to clean up there a little, won't post any links yet. But you can access them through the "Files" button in the forum menu. If you need more deps, just ask. It's been a while, not sure any more what openzwave needs.
timkoers
Member
Member
Posts: 77
Joined: Thu Jun 28, 2018 6:43 pm

Re: P1 Data injector

Post by timkoers »

Code: Select all

/qmf/sbin/hdrv_p1 -vvvv
Showed me that on some point, while sending new data, the Toon tried to create some kind of configuration file to store which values are being parsed.
There was a lot of XML on the screen and some values. Those values didn't match the last P1 telegram, but I don't know if they should.
I tried to respond to the Toon when it asked for data, but couldn't get that part working. I send data to the Toon every second and I don't get the "Handling unsolicitated meter status" warning anymore.

The Toon keeps crashing too.

Thanks marcelr! I'll try to install them on my Toon later tonight.
hvxl
Senior Member
Senior Member
Posts: 1987
Joined: Sat Jun 05, 2010 11:59 am
Contact:

Re: P1 Data injector

Post by hvxl »

timkoers wrote:How did you calculate the CRC?
I used Tcl (as I do for almost everything). There's a crc16 package in tcllib that I know correctly calculates the checksum.
timkoers wrote:I've updated the code a little and it now generates the following telegram
That checksum (02AD) is correct.
Schelte
timkoers
Member
Member
Posts: 77
Joined: Thu Jun 28, 2018 6:43 pm

Re: P1 Data injector

Post by timkoers »

hvxl wrote:
timkoers wrote:How did you calculate the CRC?
I used Tcl (as I do for almost everything). There's a crc16 package in tcllib that I know correctly calculates the checksum.
timkoers wrote:I've updated the code a little and it now generates the following telegram
That checksum (02AD) is correct.
Nice!

Is there any possibility that you and/or somebody else could check if everything matches the DSMR 5.0 standard? So if there are enough numbers, or if the accuracy needs to be increased.
I can't see my own mistakes anymore.
hvxl
Senior Member
Senior Member
Posts: 1987
Joined: Sat Jun 05, 2010 11:59 am
Contact:

Re: P1 Data injector

Post by hvxl »

timkoers wrote:Is there any possibility that you and/or somebody else could check if everything matches the DSMR 5.0 standard?
Checking your message against the DSMR 5.0 spec, I find the following discrepancies:
  • 0-0:1.0.0(180804122151W) shows winter time (W), while August is very much summer time (S)
  • 1-0:1.8.1(0000.000*kWh), 1-0:1.8.2(0000.000*kWh), 1-0:2.8.1(0000.000*kWh), and 1-0:2.8.2(0000.000*kWh) should all be F9(3,3), so 000000.000*kWh.
  • 1-0:1.7.0(0000.000*kW) and 1-0:2.7.0(0000.000*kW) should be F5(3,3), so 00.000*kW.
  • 0-0:96.13.0(0) has format Sn, where n is 2 times m. I think that means you should have an even number of hex digits. An empty value would be 0-0:96.13.0()
  • 1-0:31.7.0(000.0*A), 1-0:51.7.0(000.0*A), and 1-0:71.7.0(000.0*A) should be F3(0,0), so 000*A
I don't know if any of these issues would cause the toon to crash though. It would have to be coded very rigidly for that to happen.
Schelte
timkoers
Member
Member
Posts: 77
Joined: Thu Jun 28, 2018 6:43 pm

Re: P1 Data injector

Post by timkoers »

I've made the changes to hopefully comply with the standard now.

When testing out the script, I noticed one message from hdrv_p1.
Namely:

Code: Select all

[hcom]Received HBXT_ACTION_INVOKE from eneco-001-270500:qt-gui to eneco-001-270500:hdrv_p1/specific1: n=IsHolidayOrWeekend time=1534024800
[hdrv_p1:../../src/tariff.c@bxt_action_isLowTariffDay():18]ERROR: Time is Sun Aug 12 00:00:00 2018
This is the message that I'm sending

Code: Select all

/ISk5\MT174-001

1-0:0.0.0(64194884)
1-3:0.2.8(50)
0-0:1.0.0(180812120621S)
0-0:96.1.1(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
1-0:1.8.1(002514.718*kWh)
1-0:1.8.2(001925.348*kWh)
1-0:2.8.1(000162.835*kWh)
1-0:2.8.2(000513.956*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(00.233*kW)
1-0:2.7.0(00.000*kW)
1-0:99.97.0(0)(0-0:96.7.19)
0-0:96.13.0()
1-0:32.7.0(227.5*V)
1-0:52.7.0(231.8*V)
1-0:72.7.0(229.6*V)
1-0:31.7.0(001*A)
1-0:51.7.0(002*A)
1-0:71.7.0(002*A)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.000*kW)
1-0:41.7.0(00.000*kW)
1-0:42.7.0(00.000*kW)
1-0:61.7.0(00.000*kW)
1-0:62.7.0(00.000*kW)
!E006

The CRC doesn't match the provided message, because of the removed serial number.

I do think that the 'MeterAdapter' is providing some information

Code: Select all

[hcom]Sending HBXT_ACTION_INVOKE from eneco-001-270500:hdrv_p1 to eneco-001-270500:hdrv_zwave_6797CCD4E8C/MeterTableMonitor: n=StatusDepthGet requestId=2804-291 timeout=10
[hcom]Sending HBXT_ACTION_INVOKE from eneco-001-270500:hdrv_p1 to eneco-001-270500:hdrv_zwave_67948734E8C/MeterTableMonitor: n=StatusDepthGet requestId=2804-292 timeout=10
[hcom]Sending HBXT_ACTION_INVOKE from eneco-001-270500:hdrv_p1 to eneco-001-270500:hdrv_zwave_67958EC4E8C/MeterTableMonitor: n=StatusDepthGet requestId=2804-293 timeout=10
[hcom]Received HBXT_ACTION_RESPONSE from eneco-001-270500:hdrv_zwave_6797CCD4E8C to eneco-001-270500:hdrv_p1/MeterTableMonitor: n=StatusDepthGetResponse requestId=2804-291 repToFollow=0x00 opStatus1=0x00 opStatus2=0x00 opStatus3=0x10
[hcom]Received HBXT_ACTION_RESPONSE from eneco-001-270500:hdrv_zwave_67948734E8C to eneco-001-270500:hdrv_p1/MeterTableMonitor: n=StatusDepthGetResponse requestId=2804-292 repToFollow=0x00 opStatus1=0x00 opStatus2=0x00 opStatus3=0x10
[hcom]Received HBXT_ACTION_RESPONSE from eneco-001-270500:hdrv_zwave_67958EC4E8C to eneco-001-270500:hdrv_p1/MeterTableMonitor: n=StatusDepthGetResponse requestId=2804-293 repToFollow=0x00 opStatus1=0x01 opStatus2=0x00 opStatus3=0x00
I'm not sure what these messages mean, but I do think that it has something to do with the data request.

The second thing that I am not sure of, is if the system 'auto-syncs'. So, if the data request line stays high until data has been received, instead of going from 'Low ( 0 > data_request < 4)' to High to Low to High every second.
According to the DSMR v5.0.2 document, it looks like the line stays high until the OSM needs to stop sending (I am doubting if my little UART to USB converter can detect 4V voltage as low). I'll try to see if I can build an comparator that simulates the High impedance state of the data request line.

I've left the script on for about half an hour and some 'Handling unsolicitated meter status report' messages flew by.

Also these messages just appeared on my screen

Code: Select all

[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_67823C64E8C/Metering: n=QueryStateVariable varName=SensorStatus requestId=3097-249 timeout=5
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_67823C64E8C to eneco-001-270500:happ_kpi/Metering: n=QueryStateVariableResponse requestId=3097-249 SensorStatus=COMMISSIONING
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_67823C64E8C/ElectricityFlowMeter: n=QueryStateVariable varName=CurrentElectricityFlow requestId=3097-250 timeout=5
[libhcb_drv:../../src/statevars.c@_hdrv_bxtQueryStateVariable():63]Queried for nonexisting statevar 'CurrentElectricityFlow'
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_67823C64E8C to eneco-001-270500:happ_kpi/ElectricityFlowMeter: n=QueryStateVariableResponse requestId=3097-250 queryError=Unknown variable CurrentElectricityFlow
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_67823C64E8C/ElectricityQuantityMeter: n=QueryStateVariable varName=CurrentElectricityQuantity requestId=3097-251 timeout=5
[libhcb_drv:../../src/statevars.c@_hdrv_bxtQueryStateVariable():63]Queried for nonexisting statevar 'CurrentElectricityQuantity'
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_67823C64E8C to eneco-001-270500:happ_kpi/ElectricityQuantityMeter: n=QueryStateVariableResponse requestId=3097-251 queryError=Unknown variable CurrentElectricityQuantity
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_67848734E8C/Metering: n=QueryStateVariable varName=SensorStatus requestId=3097-252 timeout=5
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_67848734E8C to eneco-001-270500:happ_kpi/Metering: n=QueryStateVariableResponse requestId=3097-252 SensorStatus=COMMISSIONING
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_67848734E8C/ElectricityQuantityMeter: n=QueryStateVariable varName=CurrentElectricityQuantity requestId=3097-253 timeout=5
[libhcb_drv:../../src/statevars.c@_hdrv_bxtQueryStateVariable():63]Queried for nonexisting statevar 'CurrentElectricityQuantity'
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_67848734E8C to eneco-001-270500:happ_kpi/ElectricityQuantityMeter: n=QueryStateVariableResponse requestId=3097-253 queryError=Unknown variable CurrentElectricityQuantity
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_6785CFF4E8C/Metering: n=QueryStateVariable varName=SensorStatus requestId=3097-254 timeout=5
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_6785CFF4E8C to eneco-001-270500:happ_kpi/Metering: n=QueryStateVariableResponse requestId=3097-254 SensorStatus=COMMISSIONING
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_67858EC4E8C/Metering: n=QueryStateVariable varName=SensorStatus requestId=3097-255 timeout=5
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_67858EC4E8C to eneco-001-270500:happ_kpi/Metering: n=QueryStateVariableResponse requestId=3097-255 SensorStatus=UNKNOWN
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_6787CCD4E8C/Metering: n=QueryStateVariable varName=SensorStatus requestId=3097-256 timeout=5
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_6787CCD4E8C to eneco-001-270500:happ_kpi/Metering: n=QueryStateVariableResponse requestId=3097-256 SensorStatus=UNKNOWN
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_6781EFB4E8C/Metering: n=QueryStateVariable varName=SensorStatus requestId=3097-257 timeout=5
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_6781EFB4E8C to eneco-001-270500:happ_kpi/Metering: n=QueryStateVariableResponse requestId=3097-257 SensorStatus=COMMISSIONING
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_6781EFB4E8C/ElectricityFlowMeter: n=QueryStateVariable varName=CurrentElectricityFlow requestId=3097-258 timeout=5
[libhcb_drv:../../src/statevars.c@_hdrv_bxtQueryStateVariable():63]Queried for nonexisting statevar 'CurrentElectricityFlow'
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_6781EFB4E8C to eneco-001-270500:happ_kpi/ElectricityFlowMeter: n=QueryStateVariableResponse requestId=3097-258 queryError=Unknown variable CurrentElectricityFlow
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_67862C24E8C/Metering: n=QueryStateVariable varName=SensorStatus requestId=3097-259 timeout=5
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_67862C24E8C to eneco-001-270500:happ_kpi/Metering: n=QueryStateVariableResponse requestId=3097-259 SensorStatus=COMMISSIONING
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_67862C24E8C/ElectricityQuantityMeter: n=QueryStateVariable varName=CurrentElectricityQuantity requestId=3097-260 timeout=5
[libhcb_drv:../../src/statevars.c@_hdrv_bxtQueryStateVariable():63]Queried for nonexisting statevar 'CurrentElectricityQuantity'
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_67862C24E8C to eneco-001-270500:happ_kpi/ElectricityQuantityMeter: n=QueryStateVariableResponse requestId=3097-260 queryError=Unknown variable CurrentElectricityQuantity
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to eneco-001-270500:hdrv_p1_67827F84E8C/Metering: n=QueryStateVariable varName=SensorStatus requestId=3097-261 timeout=5
[hcom]Sending HBXT_QUERY_RESPONSE from eneco-001-270500:hdrv_p1_67827F84E8C to eneco-001-270500:happ_kpi/Metering: n=QueryStateVariableResponse requestId=3097-261 SensorStatus=UNKNOWN
[hcom]Received HBXT_QUERY_INVOKE from eneco-001-270500:happ_kpi to 6dd23845-1b47-4f57-9bd8-a08ec17f2e8b/GasQuantityMeter: n=QueryStateVariable varName=CurrentGasQuantity requestId=3097-262 timeout=5
[hcom]Sending HBXT_QUERY_RESPONSE from 6dd23845-1b47-4f57-9bd8-a08ec17f2e8b to eneco-001-270500:happ_kpi/GasQuantityMeter: n=QueryStateVariableResponse requestId=3097-262 CurrentGasQuantity=676251

Can somebody post their log of hdrv_p1 -vvvv when valid P1 data is being received?
timkoers
Member
Member
Posts: 77
Joined: Thu Jun 28, 2018 6:43 pm

Re: P1 Data injector

Post by timkoers »

marcelr wrote:I think that TheHogNL's suggestion is a very good one. By killing hdrv_p1 and starting it again with the -vvv option, you should see what's going on.

Nevertheless, I uploaded the openzwave package, ozwcp (controlpanel, to be installed on toon, and then to be commanded from a web browser), plus a few deps (udev, udev-utils, libmicrohttpd) to the file server. Need to clean up there a little, won't post any links yet. But you can access them through the "Files" button in the forum menu. If you need more deps, just ask. It's been a while, not sure any more what openzwave needs.
For udev_162-r12_qb2.ipk to install, it needs
* acl (>= 2.2.49) * glib-2.0 (>= 2.28.0) * libusb-compat (>= 0.1.3) *

Could you upload these as well? :D
marcelr
Global Moderator
Global Moderator
Posts: 1153
Joined: Thu May 10, 2012 10:58 pm
Location: Ehv

Re: P1 Data injector

Post by marcelr »

Done. You can find them in the same place as the rest of the packages.
timkoers
Member
Member
Posts: 77
Joined: Thu Jun 28, 2018 6:43 pm

Re: P1 Data injector

Post by timkoers »

Thanks!

I've got a strange feeling that the MeterAdapter knows which SmartMeters to accept as I constantly see this message

Code: Select all

[hcom]Received HBXT_ACTION_RESPONSE from eneco-001-270500:hdrv_zwave_6797CCD4E8C to eneco-001-270500:hdrv_p1/MeterTableMonitor: n=StatusDepthGetResponse requestId=11989-75 repToFollow=0x00 opStatus1=0x00 opStatus2=0x00 opStatus3=0x10
........
[hdrv_p1:../../src/dev_mm.c@bxt_action_HandleMeterStatus():1160]Handle unsolicited meter status report
[libhcb_drv:../../src/libhcb_drv.c@_hdrv_handleExpiredRequest():1318]WARNING: Request 12046-87 timed out, calling callback function 0x11F58 with msg NULL and args 0x1F83CE0
[hdrv_p1]StatusDepth LPC no response for handler
[hdrv_p1]uartCheck: 1 | isSmart: 0
[libhcb_drv:../../src/libhcb_drv.c@_hdrv_handleExpiredRequest():1318]WARNING: Request 12046-88 timed out, calling callback function 0x119E0 with msg NULL and args 0x1F83CE0
Post Reply

Return to “Toon software development”