Plugwise and Linux

Post by **RDNZL** » Fri Dec 12, 2008 10:10 am

DomotiGa natively can switch Plugwise circles now. And fast too!
This version will be available soon.
I'm currently busy with Power Usage, but struggling with hex/float/integer conversion routines...

Post by **Noel** » Fri Dec 12, 2008 10:37 am

Well done Ron!

Post by **Esteban** » Fri Dec 12, 2008 10:49 am

Bravo Ron! [:)]

Post by **RDNZL** » Fri Dec 12, 2008 4:54 pm

DomotiGa plugwise power usage reading also works now

2008/12/12 15:48:51 [Plugwise] GainA: 0.984963834286
2008/12/12 15:48:51 [Plugwise] GainB: -4.27852910434E-6
2008/12/12 15:48:51 [Plugwise] OffTot: 0.016127832234
2008/12/12 15:48:51 [Plugwise] OffRuis: 5.877471754111E-39
2008/12/12 15:48:51 [Plugwise] Pulses: 0015 (hex) 21
2008/12/12 15:48:51 [Plugwise] Corrected Pulses: 20.698481520899
2008/12/12 15:48:51 [Plugwise] KWH: 0.044139008994
2008/12/12 15:48:51 [Plugwise] Watt: 44.139008993752

Regards,
Ron

Post by **Snelvuur** » Fri Dec 12, 2008 5:29 pm

nice work for that too ron, does those have rrdtools on top of it too?

// Erik (binkey.nl)

Post by **RDNZL** » Fri Dec 12, 2008 5:44 pm

I only have to poll all circles every x minutes to read and store the values.
And yes if you enable Graphing and configure Value2 as Watt/GAUGE it will be graphed by rddtool.

Now I only need to find some time to commit all the changes.

Post by **Snelvuur** » Fri Dec 12, 2008 5:50 pm

well it should be very very easy,... with that svn repository..

// Erik (binkey.nl)

Post by **RDNZL** » Fri Dec 12, 2008 5:56 pm

Thats the easy part, but I had to change the database layout and content too, defined new modules like Plugwise Stick and Circles ...
And I have two party's this weekend [:o)]

Post by **TANE** » Fri Dec 12, 2008 5:58 pm

Nice Work..

I wish some of your plugins where available for Homeseer

Post by **t006** » Mon Dec 15, 2008 10:37 pm

Maarten,

Can we also do some feature requests?

- Read the status of the plug (is it set on or off)
- Read total usage of the plug and/or the history.
- Upload schedules to the plug

If we have this options we don't need source anymore that often.

Post by **Bwired** » Sun Jan 04, 2009 3:07 am

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by Bwired
 Hi Maarten,
I think this is for me the trigger to contact Plugwise and ask them for cooperation.
It's better for Plugwise to give a subset of the specifications now, this way we can make a very nice Linux driver and a real Homeseer plugin etc.
The only thing we want is to get information from the circles, give On and Off commands and be able to upload timers etc.
I saw the information you retrieved from the dongle some months ago with the use of Serial port monitor. http://www.serial-port-monitor.com/
I was not able to quickly translate the CRC etc, so great job on that!
I'll get back on this!
<hr height="1" noshade id="quote"></blockquote id="quote">Still no answer from Plugwise on releasing the API specification, quess they are not seeing the benifit of it

Post by **Mdamen** » Sun Jan 04, 2009 4:37 pm

@t006: sorry for not replying didn't read that last post, however I'm fullfilling two of your requests in this post

Offcourse you guys can request, I'll put it on my to-do list then!

As promised I would publish some information about the power buffers.

Circle information request

You can read some information about the plugwise device, some values are unknown. But, I already want to share this because it's needed for power buffer reading.

Let's analyze the information request:

Code: Select all

0023000D6F00002366BB231B

- The first 4 bits represent the function code, which is in this case "0023"
- The next 16 bits represent the MAC address of the device, which is in this case "000D6F00002366BB"
- The last 4 bits represent the CRC16 checksum value, in this case "231B"

Let's analyze the information response:

Code: Select all

0024 000D6F00002366BB00003681 000457C8 01 8500000473000748B4253801F74D

Note: the spaces have been included for readability.

The first 4 characters represent the function code, in this case information response.
The next string is the mac address.
Now for the interesting part:

- 000457C8 represents the last logaddress value hexadecimal. This logaddress is used for power buffer information.
To get the logaddress in nice decimal format, do the following:

1) Convert the hexadecimal value to integer.
2) Substract 278528 from the outcome.
3) Divide that outcome by 32.

The result will be the latest log address of the power buffers.

My calculation looks like this:

Code: Select all

(self.hexToInt(data) - 278528) / 32

These logaddresses are also visible in the plugwise database.

- 01 represents the current relay state of the device (01=ON, 00=OFF)

The other values are yet unknown. Also because I wasn't interested in these values yet.

Power buffer information

The circle's hold an internal buffer of power usage. This way you can safely close the source software and read that information later on. I have succeeded in reading this without using the source.

Let's analyze the power buffer request:

Code: Select all

0048 000D6F0000236317 00045640 439B

- The first 4 bits represent the function code, which is in this case "0048"
- The next 16 bits represent the MAC address of the device, which is in this case "000D6F0000236317"
- The next 8 bits represent the log address of the power buffer you want to fetch, remember we read the latest buffer address with the information request? You can use this to determine the buffers you are missing in your program, for example if the latest log address is 160 and the last processed buffer in your program is 150 you are missing 10 buffers starting from 150 (so you would do a read request here for 151, 152 etc.)
The log address requires some ca****ation (again) In this case the log address is:

- 00045640 to decimal 284224
- 284224 - 278528
- 5696 / 32 = 178

So the log address is 178.

To calculate the hexadecimal for a log address one would just reverse the formula:

The log address is 178.
278528 + (32 * 178) = 284224

Converting this to hexadecimal is: 00045640

- The last 4 bits represent the CRC16 checksum value, in this case "439B"

Let's analyze the power buffer response:

Code: Select all

0049 000D6F0000236317 000036B1 0000ABAA 000036B2 0000AB72 000036B3 0000AB66 000036B4 0000ABAD 00045620 758F

This is a huge one [:)]

- The first 4 bits represent the function code, which is in this case "0049"
- The next 16 bits represent the MAC address of the device, which is in this case "000D6F0000236317"
- The next 8 bits represent the hour of the first buffer in abshour format (got this name from the access database

) more about this abshour format later.
- The next 8 bits represent the usage in pulses for the first hour.
- The next 8 bits represent the hour of the second buffer in abshour format (got this name from the access database

) more about this abshour format later.
- The next 8 bits represent the usage in pulses for the second hour.
- The next 8 bits represent the hour of the third buffer in abshour format (got this name from the access database

) more about this abshour format later.
- The next 8 bits represent the usage in pulses for the third hour.
- The next 8 bits represent the hour of the fourth buffer in abshour format (got this name from the access database

) more about this abshour format later.
- The next 8 bits represent the usage in pulses for the fourth hour.
- The next 8 bits represent logaddress of the buffer, this is the same log address as explained before.
- The last 4 bits represent the CRC16 checksum value, in this case "758F"

The abshour format
Let's pick the first buffer address as example: 000036B1
The decimal value of this abshour value is 14001

This value was a real brain cracker, after comparing the values I figured out the following.
For illustration let's convert the next abshour value (000036B2) to decimal: 14002

Aha! It increases by one all the time, so there must be a constant in these values. Then I substracted this value as hours from the current date (as it states abshour I was figuring it had something to do with hoours) this brought me to the following date:

1-6-2007

So if you add the number of hours to that date you'll get the datetime of that buffer.
Example in python:

Code: Select all

>>> import datetime
>>> timestart = datetime.datetime(2007, 6, 1, 2)
>>> dif = datetime.timedelta(hours=14001)
>>> datetime = timestart + dif
>>> datetime
datetime.datetime(2009, 1, 4, 11, 0)

So the date and time of this buffer request is:
4-1-2009 11:00

The pulses
I have explained these pulses before in a post. The pulses here are exactly the same pulses, however there is one difference.
The formula must be changed from:

1.0 * (((pow(value + offruis, 2.0) * gain_b) + ((value + offruis) * gain_a)) + offtot)

To:

3600 * (((pow(value + offruis, 2.0) * gain_b) + ((value + offruis) * gain_a)) + offtot)

Also you need to divide the pulses value by 3600.
This is needed because the pulses are now logged for an entire hour rather then a second.
I use a generic function now for the pulsecorrection:

Code: Select all

    def PulseCorrection(self, pulses, id, timespan):
        """
        Corrects plugwise pulses using calibration information from plug.
        """
        device = Device.get(int(id))
        value = pulses / timespan;
        out = timespan * (((pow(value + device.extension.offruis, 2.0) *\
        device.extension.gainb) + ((value + device.extension.offruis) * \
        device.extension.gaina)) + device.extension.offtot)
        return out

Phew.. this is gotten a really long post, I hope it's clear enough and that it's usefull for you. If you have any questions don't hesitate to ask.

--
Maarten Damen

www.maartendamen.com

Post by **Willem4ever** » Sun Jan 04, 2009 6:03 pm

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by Bwired
Still no answer from Plugwise on releasing the API specification, quess they are not seeing the benifit of it

<hr height="1" noshade id="quote"></blockquote id="quote">I enjoyed a lengthy discussion on this subject during the domotica fair, but Plugwise was very clear, they have no intention to disclose it. It's a pitty ...

Post by **Rene** » Sun Jan 04, 2009 10:07 pm

@Maarten: Thank you very much for this information, I will start rewriting my Homeseer plugin to communicate directly to the Circles, bypassing the source software.

Just out of curiousity; Does every Circle buffer it's usage information or is all information buffered on the Circle+?

Rene.

Post by **Mdamen** » Sun Jan 04, 2009 11:18 pm

Each circle has it's own information.
If you need any help feel free to contact me by e-mail.

--
Maarten Damen

www.maartendamen.com