Black Box Interface wish list

[RossW]

I must have missed that email?

I'll resend it now - but will catch you in IRC.

[dgd]

Ross,

Have you written or adopted some C code for this modbus reader? And compiled it on the rPi?
Or is it interpreted code of some sort?
Although you say it's not intended to replace the local app,   your program with parameter input on command line is ideal for shell scripting, I would actually like to see a web page that replaces the local app, at least the live metering part.
To this end I have several C functions  that implement the multiple register read and write commands and have used these to create a date update program for the classic lite.
My ongoing project now is getting a live web page that shows a continuous changing of the basic classic volts,amps,watts,energy,temp readings.
And in a skinned type graphical dashboard.
Including reporting in this is not my goal as after event reporting can be handled by many available graphing packages.
Anyway, you have made good progress, good to see. 

Dgd

[RossW]

Ross,
Have you written or adopted some C code for this modbus reader?

Written in straight C from scratch, no copied, borrowed or GPL (etc). All my own original work, so unencumbered!

And compiled it on the rPi?

I developed locally under FreeBSD, sent the source and virtually no instructions apart from "cc -o modbus modbus.c" to TomW, who compiled on one of his boxes and then later on one of his pi's.

Or is it interpreted code of some sort?
Although you say it's not intended to replace the local app, Andrew your program with parameter input on command line is ideal for shell scripting, I would actually like to see a web page that replaces the local app, at least the live metering part.
To this end I have several C functions  that implement the multiple register read and write commands and have used these to create a date update program for the classic lite.
My ongoing project now is getting a live web page that shows a continuous changing of the basic classic volts,amps,watts,energy,temp readings.
And in a skinned type graphical dashboard.
Including reporting in this is not my goal as after event reporting can be handled by many available graphing packages.
Anyway, you have made good progress, good to see. 

I already log, and display "near-real-time" (only updated every 300 seconds - but that's entirely for other reasons, could be constantly updated if you wanted).

A VERY clunky PoC (just so I could see it on my mobile phone) is as Tom posted earlier: http://ranges.albury.net.au/midnight/classic.shtml

Yes, scripting things with it is the purpose.
It currently writes to registers using the = (assign) primative.
It'll write a string or an integer - so formatting to take time is easy enough to do, but messy. I'm going to add a switch (perhaps -ts?) to automatically time-sync the midnite to local clock.

[Graham]

I've been tinkering with my own 'black box' interface to my classic lite (https://netduinosolar.codeplex.com/), I have an arduino shield that includes a real time clock and I was hopping to set the classic lite date-time. I unlocked the classic by writing the serial# to register 20492, then wrote the date-time to registers 4214 - 4218. The write succeeds but the classic time remains at 2003...
I was wondering if anyone would share a code snippet that demonstrates how to set the date-time on a classic-lite.

thanks
Graham.

[dgd]

Time in 4213 (16bit integer 0 to 15360 incrementing counter for an hour with value/256 for minute count and remainder/256*60 for seconds) and 4214 (byte day of week but I'm not sure it is, byte hour,  date in 4125 (byte day byte month) and 4216 is 16 bit year.
I don't think 4217 and 4218 are involved but I'm usually wrong...

I will get the c routine I wrote for this and post later.

Dgd

[RossW]

I've been tinkering with my own 'black box' interface to my classic lite (https://netduinosolar.codeplex.com/), I have an arduino shield that includes a real time clock and I was hopping to set the classic lite date-time. I unlocked the classic by writing the serial# to register 20492, then wrote the date-time to registers 4214 - 4218. The write succeeds but the classic time remains at 2003...
I was wondering if anyone would share a code snippet that demonstrates how to set the date-time on a classic-lite.

I just got to that part of my own code today... and have encountered the same problem. Even with the "LOCK" jumper in the unlocked position.  I'm pretty sure my code is right too, looking at the bytes being actually sent:

Code Select Expand


% ./classicmodbus -td `cat classic.addr`         
ID Solar2
Classic Time 10:14:44 26/05/2013
System Time 10:15:15 26/05/2013
Write 00 02 00 00 00 0f ff 10 10 75 00 04 08 0f 0f 00 0a 05 1a 07 dd
Read 7 (header) bytes: 0 2 0 0 0 6 ff


So lets strip off the tcp encapsulation, look only at the relevant modbus bits:
10 10 75 00 04 08 0f 0f 00 0a 05 1a 07 dd

10 - "write multiple registers".
1075 -> 4213 decimal = (4214-1) = correct starting register.
0004 -> 4 registers to write.
08 -> 8 bytes to send. (4 x 16-bit registers = 8 bytes)

now comes the messy stuff. 0f0f000a should be the "time", per the structure provided.

I'm using a structure, rather than bit shifting and masking - not sure it's any easier, but it's tidier, and self-documents the code.

Code Select Expand


        typedef union
        {
                struct
                {
                        unsigned int sec : 6;   // bits 5-0 are seconds
                        unsigned int void1 : 2; // unused
                        unsigned int min : 6;   // bits 13-8 are minutes
                        unsigned int void2 : 2; // unused
                        unsigned int hrs : 5;   // bits 20-16 are hours
                        unsigned int void3 : 3; // unused
                        unsigned int dow : 3;   // bits 26-24 are day-of-week
                        unsigned int void4 : 5; // unused
                }time;
                struct
                {
                        unsigned int day : 5;   // bits 4-0 are day of month
                        unsigned int void1 : 3; // unused
                        unsigned int month : 4; // bits 11-8 are month
                        unsigned int void2 : 4; // unused
                        unsigned int year : 12; // bits 27-16 are hours
                        unsigned int void3 : 4; // unused
                }date;
                unsigned int raw;
        }classictime;


so 0f0f000a should be read as 000a0f0f when re-assembled
0000000000001010.0000111100001111

breaking into logical bitwise fields

Code Select Expand


xxxxx000xxx01010.xx001111xx001111
                                               ^^^^^-- 15 seconds
                                 ^^^^^------------- 15 minutes
                   ^^^^-------------------------- 10 hours
        ^^^------------------------------------ day 0 (sunday)


That's exactly what it should have been:   System Time 10:15:15 26/05/2013

Doing the same thing with the date:
05 1a 07 dd  ->  07dd051a = 0000011111011101.0000010100011010

Code Select Expand


xxxx011111011101.xxxx0101xxx11010
                                                 ^^^^--- 26 days
                                     ^^^-------------- 05 month
       ^^^^^^^^^-------------------------- 2013 year


Which is also correct... only thing I haven't done is set the day-of-year. Not sure that's even important but I'll try it.

.... ok, back (did you blink?).

Changed to send 10 bytes (not , and included setting the "day-of-year", but still ignoring me.

I think we need Bob or Andrew to advise on this one!

[boB]

Hi guys...

I stumbled onto this just now.
As you know, I am updating the modbus document and I've found the problem
which is a bit of an error in the doc.

You're probably not going to like it though.

The doc says Write Only.  Well, these 3 CTIME (Consolidated Time) Registers
are actually Read Only.  You have to set the Classic's time and date through
file transfer at the moment which I am adding to the documentation.
Since file transfer is a bit harder to deal with than just reading or writing
registers, I think I will either add separate registers for  Sec, Min, DOM, Year, etc.

Sorry you've wasted your time here but at least now we know why it did not work.
boB

From the manual....

6.3 Consolidated time registers
The values of the Time Counters can optionally be read in a consolidated format which
allows the programmer to read all time counters with only three read operations. The
various registers are packed into 32 bit values as shown in Table 26â€"507, Table 26â€"508,
and Table 26â€"509. The least significant bit of each register is read back at bit 0, 8, 16, or
24.
The Consolidated Time Registers are read only. To write new values to the Time
Counters, the Time Counter addresses should be used.

[dgd]

boB,
So how is the MNGP writing the current date and time to the Classic? If its not writing to modbus registers is there a serial port command that it uses to set time and date?
Why not just make the time/date modbus registers writeable?  Does it really matter what the docs say? There is likely a r/o or r/w flag or mode table for the modbus registers

Dgd

[boB]

boB,
So how is the MNGP writing the current date and time to the Classic? If its not writing to modbus registers is there a serial port command that it uses to set time and date?
Why not just make the time/date modbus registers writeable?  Does it really matter what the docs say? There is likely a r/o or r/w flag or mode table for the modbus registers

Dgd

The MNGP presently uses modbus file transfer to set the time registers because it also sets the sunrise and sunset from
the earlier wizard.

I will add registers to set time/date with and then you will have to set a Force Flag to actually transfer the values
to the timer.

boB

[RossW]

I will add registers to set time/date with and then you will have to set a Force Flag to actually transfer the values
to the timer.

Not sure any of us particularly mind how it's done, if it's clearly documented so we can do it

[Graham]

 Thanks for the responses, look forward to seeing the updated docs.

[RossW]

There are probably bits of this thread/discussion scattered across the forum.
Trying to pull it back into one place if I can!

For those who wanted to try it, here are precompiled binaries of the current version:
http://support.rossw.net/midnite/newmodbus.PI for Raspberry Pi with Raspbian on it.
http://support.rossw.net/midnite/newmodbus.PC for Ubuntu 11.10
http://support.rossw.net/midnite/newmodbus.OSX for Mac OS/X

This version doesn't autodiscover classics, it requires you to tell it the IP address.

Once downloaded, run it like this:

Code Select Expand


./newmodbus -p 192.168.1.63    (whatever your classic IP address is)
Solar2 Display Panel 1.0.13, RossW
State BulkMppt
Firmware 1401
ClassicTime 13:27:04  10/06/2013
  759 Watts out
50.4 Volts (Battery)
102.9 Volts (PV)
15.0 Amps (Battery)
  5.5 kWh today (100 amphours)


[RossW]

For those who wanted to try it, here are precompiled binaries of the current version:

I've updated the code - under some conditions one of the buffers was overrunning while sending data.

[zoneblue]

HI Guys,

I have ross's newmodbus running on my web dev server, which is a 2year old dual core atom so it draws 19W (that's well due for a rebuild (waiting for silvermount)). Given this is as much as the fridge ive ordered a cubieboard, and will run in on that for now.  However it got me thinking about the pending release of the battery monitor addon and how the black box idea would be ideal for every classic owner that doesnt have access to a inverter or flexnet based monitoring system.

Options :

- arm dev board with a case

- ready made hackable version of above, eg mele
http://dx.com/p/mele-a2000-1080p-android-2-3-network-multi-media-player-w-sata-usb-hdmi-lan-vga-wifi-4gb-131566

- cheap tablet, over wifi, or ethernet over usb

For my 2c browser viewable is enough. Or if people wanted a small LCD or something like that, i guess there'd be options. rPi folk would know.

All sorts of options, but mele does seem like a cheap easy solution to me.

Im happy to share my UI code, when its done, but those of interested could, like, cooperate.

[Graham]

HI Guys,

I have ross's newmodbus running on my web dev server, which is a 2year old dual core atom so it draws 19W (that's well due for a rebuild (waiting for silvermount)). Given this is as much as the fridge ive ordered a cubieboard, and will run in on that for now.  However it got me thinking about the pending release of the battery monitor addon and how the black box idea would be ideal for every classic owner that doesnt have access to a inverter or flexnet based monitoring system.

Options :

- arm dev board with a case

- ready made hackable version of above, eg mele
http://dx.com/p/mele-a2000-1080p-android-2-3-network-multi-media-player-w-sata-usb-hdmi-lan-vga-wifi-4gb-131566

- cheap tablet, over wifi, or ethernet over usb

For my 2c browser viewable is enough. Or if people wanted a small LCD or something like that, i guess there'd be options. rPi folk would know.

All sorts of options, but mele does seem like a cheap easy solution to me.

Im happy to share my UI code, when its done, but those of interested could, like, cooperate.

Does the mele have a Real Time Clock? I had to build a custom shield that included an RTC for my netduino based monitor so I could log data from a classic lite which doesn't have a clock.