As further work on the blackbox project UI was pending resolution of sample rate issues, and no improvement in the timeout issue materialised with the last firmware update, it was decided to work up a daemon version of RossW's newmodbus. This allows us to sample at smaller intervals continuously, utelising a single open modbus connection to the classic.
Im happy to say it works and at a 1s sample rate is stable. However as c is not my native language, hopefully others can give some feedback on it. Source code for both newmodbusd, and the original newmodbus (thanks to Ross) are now up at the blackbox project svn. (http://code.google.com/p/theblackboxproject/source/browse/trunk) in folder 'c'. There is a binary compile of newmodbusd for ARM there too, to get it click 'show details' then 'view raw file' in the right sidebar.
For those perservering with cron/newmodbus, it has been determined on three seperate systems that 3 minute intervals is the fastest sample rate that is stable on the ARM architecture. But short of a firmware miracle my focus will be moving on to this daemon methodology. The upside is that using ajax we will now be able to get near real time data into the UI. The downside is that to use the local app you will first need to unplug blackbox. Not ideal, but bearable i guess.
The downside is that to use the local app you will first need to unplug blackbox. Not ideal, but bearable i guess.
Wouldn't a A/B switch be usable here?
Quote from: Westbranch on January 11, 2014, 06:43:48 PM
The downside is that to use the local app you will first need to unplug blackbox. Not ideal, but bearable i guess.
Wouldn't a A/B switch be usable here?
Since it's TCP/IP, no need to physically disconnect anything. All that's required would be to stop the process on the blackbox system to permit the local-app to connect (since the classic only allows one connection at a time)
The other possible fix for this would be to have a "mirror mode" in the daemon that will accept connections on the same port as the classic and to "pass through" from local app to the classic.
Degrees of cleverness could be added. The daemon could maintain a table that is a copy of the registers in the classic, and when the local app requests a register, the daemon could immediately reply with its local (cached) copy instantly. If it was a register that wasn't cached (perhaps the special purpose registers), or a command for something else (like to read log files etc), they could be passed through.
Where a passthrough is happening, the daemon should be smart enough to arbitrate and interleave the local-app requests with its own needs so both devices could operate transparently.
(Only possible fly in the ointment will be the mysterious udp broadcasts the classic does to announce itself. Either the daemon would need to do the same thing, or hopefully the local app has a mode to specify the IP address of the classic, so you can point it to the "mirror" rather than the actual classic)
I see you have thought about coding up newmodbusd so it would act as a modbus proxy for the Classic. (damon) Say, to keep things simple, for read-only requests? Then we could have diverse apps connect to it in parallel and monitor the Classic. I thinbk that would be a great projedct and we had some threads here about this a while back.
newmodbusd maintains a text file containing the entire register range, at near realtime. It would be realtively simple im sure to write a tiny server which handles modbus requests. However another route would be to factor it more as a http api, thus utelising the existing webserver.
- http://blackbox/api.php?readmodbusrange=4110-4130
- http://blackbox/api.php?readdatapts=vbat,icc,iwb,soc
etc, type of thing. Im not really sure what kinds of devices would be consuming such data to say which would be best.
I like the approach of using an API as a go between. It seems like it would work for lower powered devices to just act as a go-between to a cloud server or something.
I've finally gotten a look at theblackbox code today, and trying to make it run on my iMac (instead of doing actual work). I think the Beagle can handle everything, but I'm thinking it'd be nice (long term) to be able to push the data to my web server so it's accessibly remotely, tons more storage and processing power, etc.
I really should have done some real work today, heh.