[WIP/Released] P1 Data injector

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

Moderator: marcelr

[WIP/Released] P1 Data injector

Postby timkoers » Thu Aug 02, 2018 6:51 pm

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 7:47 am, edited 6 times in total.
timkoers
Starting Member
Starting Member
 
Posts: 41
Joined: June 2018

Re: P1 Data injector

Postby marcelr » Thu Aug 02, 2018 9:56 pm

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.
marcelr
Advanced Member
Advanced Member
 
Posts: 938
Joined: May 2012
Location: Ehv

Re: P1 Data injector

Postby hvxl » Fri Aug 03, 2018 12:24 pm

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
hvxl
Senior Member
Senior Member
 
Posts: 1111
Joined: June 2010

Re: P1 Data injector

Postby timkoers » Fri Aug 03, 2018 3:31 pm

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
Starting Member
Starting Member
 
Posts: 41
Joined: June 2018

Re: P1 Data injector

Postby timkoers » Sat Aug 04, 2018 12:47 pm

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.
timkoers
Starting Member
Starting Member
 
Posts: 41
Joined: June 2018

Re: P1 Data injector

Postby TheHogNL » Sat Aug 04, 2018 6:23 pm

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
User avatar
TheHogNL
Advanced Member
Advanced Member
 
Posts: 545
Joined: August 2017

Re: P1 Data injector

Postby marcelr » Sun Aug 05, 2018 3:35 pm

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.
marcelr
Advanced Member
Advanced Member
 
Posts: 938
Joined: May 2012
Location: Ehv

Re: P1 Data injector

Postby timkoers » Sun Aug 05, 2018 4:28 pm

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.
timkoers
Starting Member
Starting Member
 
Posts: 41
Joined: June 2018

Re: P1 Data injector

Postby hvxl » Wed Aug 08, 2018 4:00 pm

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
hvxl
Senior Member
Senior Member
 
Posts: 1111
Joined: June 2010

Re: P1 Data injector

Postby timkoers » Fri Aug 10, 2018 7:05 pm

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.
timkoers
Starting Member
Starting Member
 
Posts: 41
Joined: June 2018

Re: P1 Data injector

Postby hvxl » Fri Aug 10, 2018 9:06 pm

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
hvxl
Senior Member
Senior Member
 
Posts: 1111
Joined: June 2010

Re: P1 Data injector

Postby timkoers » Sun Aug 12, 2018 11:59 am

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
Starting Member
Starting Member
 
Posts: 41
Joined: June 2018

Re: P1 Data injector

Postby timkoers » Mon Aug 13, 2018 9:12 am

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
timkoers
Starting Member
Starting Member
 
Posts: 41
Joined: June 2018

Re: P1 Data injector

Postby marcelr » Mon Aug 13, 2018 10:02 am

Done. You can find them in the same place as the rest of the packages.
marcelr
Advanced Member
Advanced Member
 
Posts: 938
Joined: May 2012
Location: Ehv

Re: P1 Data injector

Postby timkoers » Mon Aug 13, 2018 10:06 am

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
timkoers
Starting Member
Starting Member
 
Posts: 41
Joined: June 2018

Next

Return to Toon software development

Who is online

Users browsing this forum: No registered users and 1 guest

cron