Android app for the Classic

[Graham]

I'm working on an android app that displays the charge status of a classic over modbus. It's very basic at this point, it will display a gauge view in landscape and a simple list in portrait. It requires a minimum of android API level 15 (version 4.0.3+).

If anyone would like to try it, let me know if it displays correctly on your device, It renders correctly on a nexus 10, I've also tried a galaxy 4 using the emulator.

I haven't completed the settings page, so the gauge scales are currently fixed. 

By default it will scan your local network for port 502, you can set a static IP address or change the port number in the settings.

Since it is not on google play, you will have to allow installation of apps from 'unknown sources', otherwise known as sideloading explained at http://phandroid.com/2013/07/20/android-101-sideloading-apps/.

The APK file is in a public folder on DropBox https://dl.dropboxusercontent.com/u/217460186/Classic/Classic.apk . (click on this link within your device to install)

The source is on SourceForge at https://sourceforge.net/projects/classicmonitor/.


Main Status Page


Graham.

[Halfcrazy]

Graham
Very Very nice. It did not seem to auto detect my classic but when I plugged it in manually it worked. It found something on port 502 at IP 192.168.2.16 and all my Classics are from 190 to 200. When the sun comes up I will play with it more but this is Way Way cool. Any plans to add support for the WBjr?

Ryan

[Graham]

Thanks Ryan, I'm planning on getting a WBjr, I could display the battery current gauge as an automotive gauge with +/- amps.
I'll probably add a log screen to help me debug issues like the scan problem, the code used the gateway address and subnet mask to come up with a scan range, it then uses a thread pool to attempt to connect to each address with the given port, I could add a scan range in the settings as an option to limit the range of addresses.

Graham.

[Halfcrazy]

So I was playing with it here and it keeps disconnecting and reconnecting like every 2 seconds. I am running a Galaxy S3 with Android 4.3.0010

[Graham]

Looks like your getting a modbus exception from the J2Mod library. I`m currently limited to testing against a modbus slave simulator with a galaxy S3 emulator (which don't report any connection errors), I`ll have to try this against my classic this weekend when I get back to my cabin. The last time I was there, my Nexus 10 was able  to remain connected to the (real) classic.
I'm considering replacing the J2Mod with my own implementation, this would allow me to implement the custom file transfer in order to get the logs off the classic so I can chart the data, it would also allow more control over the tcp settings/timeouts etc.
Are you using a tool like wireshark to see the error? If you are can you send me a screen capture?

[Halfcrazy]

Let me see if I can run Wire shark and get the info. It may be tomorrow before I can but I will try my best

[RossW]

I'm considering replacing the J2Mod with my own implementation, this would allow me to implement the custom file transfer in order to get the logs off the classic so I can chart the data, it would also allow more control over the tcp settings/timeouts etc.
Are you using a tool like wireshark to see the error? If you are can you send me a screen capture?

newmodbus - the utility I wrote about a year back - went the same way. The available modbus libraries were clunky, slow and unnecessarily convoluted to use. So I coded all the classic stuff straight in. It's actually pretty straightforward, don't let the documentation scare you. modbus-over-tcp is basically just building the same modbus frame you would if it were over serial, then adding a small header to it to transport over tcp.

If your code is written in C, I'm happy to share the relevant bits of my code to get you on the way?

R.

[zoneblue]

Hey Ross, ive almost finished with the daemon version of newmodbus. Its running fine sampling once per second, on the second +/-1ms. 

The newmodbusd 1 second rate will allow us to use ajax to get real time primary stats. And, do way more accurate Wh, Ah and similar integrations.  It also matches the classic internal 1sec averaging scheme.

What i'm doing is storing the regsiter data in a temp file, then renaming it when done. This seems to be giving me the high availability to other applications that i needed.

Just got a few decisions to make about summarising the rather prolific raw data.

[RossW]

Hey Ross, ive almost finished with the daemon version of newmodbus. Its running fine sampling once per second, on the second +/-1ms. 

Great news. Is this based on a pulled-apart-and-re-assembled version of the newmodbus code I sent you?
Did you ever see a repeat of the network bug we thought related to the processor type (or did that go away when you recompiled native for your processor)?

[zoneblue]

Great news. Is this based on a pulled-apart-and-re-assembled version of the newmodbus code I sent you?

Yes. Dragged kicking and screeming into c.

Did you ever see a repeat of the network bug we thought related to the processor type (or did that go away when you recompiled native for your processor)?

Even when complied on cubie the classic timeout issue remained. Working down from 5 minute samples, 5 was fine, 4 was fine, 3 was fine. 2 minutes starts to drop occasional samples, and locks up after about a week. 1 minute drops lots of samples and classic locks up after about 14 hours.

So, on a open-read-close basis, its stable at 3 minute sample intervals or higher.

I did manage to locate the via eden 400Mhz x86 box, but havent got around to trying it. But im not really sure theres much point. The ARM boards are here to stay, at least for now. Lets say, hypthetically that timeouts dont occur on a slow x86 box what does that gain us? The only upside that i can see is the possibility of, maybe, providing some key clue that will help midnite actually solve the problem.

But given midnite's other priorities, this daemon route is at least a way forward, allowing further development on blackbox UI.

The point being is that if you maintain an open modbus connection, its stable and theres no timeouts, or refused connects. Even if most peoples application is just 60s cron job to read the text file produced by the daemon.

Ross, will you be ok if i include the both your and my source in the blackbox svn? Attributions obviously.

[RossW]

Yes. Dragged kicking and screeming into c.

lol.

The point being is that if you maintain an open modbus connection, its stable and theres no timeouts, or refused connects. Even if most peoples application is just 60s cron job to read the text file produced by the daemon.

*nod*, and you know the history of the reason I added the "keep connection open" logic in the code

Ross, will you be ok if i include the both your and my source in the blackbox svn? Attributions obviously.

Yup.

[mjp24coho]

Android app is great, but I would think there'd be an even bigger market for an apple app.  Anyone have one in the works?

[Graham]

I'm considering replacing the J2Mod with my own implementation, this would allow me to implement the custom file transfer in order to get the logs off the classic so I can chart the data, it would also allow more control over the tcp settings/timeouts etc.
Are you using a tool like wireshark to see the error? If you are can you send me a screen capture?

newmodbus - the utility I wrote about a year back - went the same way. The available modbus libraries were clunky, slow and unnecessarily convoluted to use. So I coded all the classic stuff straight in. It's actually pretty straightforward, don't let the documentation scare you. modbus-over-tcp is basically just building the same modbus frame you would if it were over serial, then adding a small header to it to transport over tcp.

If your code is written in C, I'm happy to share the relevant bits of my code to get you on the way?

R.

I`d be very interested in some of your modbus code, I found J2Mod easy to use but it doesn't appear to have many options for tcp settings/config. This is my  first Android app, I'm using the new Android Studio with Java. It's been a few years since I used good old 'C' but I'm sure it will all come back to me.

Graham.

[Graham]

Android app is great, but I would think there'd be an even bigger market for an apple app.  Anyone have one in the works?

I decided to write this app as an exercise to learn mobile development with the new Android Studio recently release by Google, but if I was going to target all platforms I would consider using Phonegap and Phonegap.build. This is one of the tools used in 'hybrid' mobile development, http://en.wikipedia.org/wiki/PhoneGap. You write your app in javascript using the phonegap library + jquery/dojo etc, then submit the code to phonegap.build and it returns executables for each of the major mobile platforms (Android, IOS, Blackberry, Windows phone).

[vtmaps]

but if I was going to target all platforms I would consider using Phonegap and Phonegap.build.

Another multiplatform development environment is Livecode (formerly Runtime Revolution).   --vtMaps