Linux Web Front End Development Thread

[PaulF]

Quote: Originally Posted by cgalpin

On a related note, I want to mention an idea I have regarding the FB. I'll preface this by saying I don't know jack about OBD...

For anything I use the FB for that has OBDII analogs, I'd like to create a ODII simulator which servers the data collected just as if you'd get it from an OBDII vehicle.

The benefits are

1. I suspect most people wanting to collecting these things (rpm,temps,maf sensors etc.) will be able to leverage this with at most configuration changes.
2. Those using the FB can then leverage all the OBDII based tools out there for display, including this web based stuff
3. We attract a larger pool of people interested in this web based stuff if it's not just about FB interaction.

Let me just clarify to make sure I understand...
You want to make a driver which pretends to be an OBD reader but is actually taking in values from another source?

[PaulF]

[Nitpicking]

Quote: Originally Posted by Bugbyte

...with a web server like ampache...

Apache is the web server, ampache is a web application for apache which does sound stuff.
[/Nitpicking]

[cgalpin]

Quote: Originally Posted by PaulF

Let me just clarify to make sure I understand...
You want to make a driver which pretends to be an OBD reader but is actually taking in values from another source?

No, not a reader but a provider. A daemon that provides a serial port that you connect to and talk the obd protocol. But the data it provides doesn't come from an ECU but from a FB. So I guess it simulates the ELM protocol.

[kev000]

Quote: Originally Posted by red_parchel

Guys there are many awesome idea's here, and I'll admit I'm not much of a web programer. but i do believe in the open source ideals and i believe there is no need to reinvent the wheel. this said i may have a suggestion for the media side of things, ampache is a web based music jukebox that does a few things, which includes the ability to plug music from the website ON the server [using mpd] or stream music from the server to the client [ether a flash player or via a playlist opened in a local app] .. I feel this model is great and there may be some useable code in this project. and if we decided to go this route I'd be more than willing to help in this department. If you guys decide to go another route then heck i can help out w/ something else too!

Hope there is something useful in there! I like the direction you guys are headed!

and i like the idea of being able to keep it all seporated .. if i teathered my cell phone to the plug i could montior my car from my home webbrowser [it'd feel like a race car driver with a team monitoring the car!!!]

Audio prioritization
Moblin has a project they call "Audio Manager". For nGhost3 we were going to write a simpler version of the same thing. It makes sure that the sound device isn't going to be used at the time by other apps. Whatever backed we chose for audio playback, it must be able to tie in with this system.

[PaulF]

Quote: Originally Posted by cgalpin

No, not a reader but a provider. A daemon that provides a serial port that you connect to and talk the obd protocol. But the data it provides doesn't come from an ECU but from a FB. So I guess it simulates the ELM protocol.

By reader, I meant physical reader because that is what any OBD program would see it as.

Yes this would be very cool, but I can't imagine the programming involved...

[cgalpin]

Yup, we are on the same page. I haven't looked into it, but I'm willing to bet an OBDII simulator exists, and if so then the task shouldn't be that hard.

[PaulF]

Quote: Originally Posted by cgalpin

Yup, we are on the same page. I haven't looked into it, but I'm willing to bet an OBDII simulator exists, and if so then the task shouldn't be that hard.

I saw a thread in the past week with someone asking for one. They were complaining that no one offers a cheap one. So that may be more difficult than we think. We'll have to see though...

[PaulF]

Actually, I just found that thread and malcom2073 has already made an OBD simulator and released the source!
http://www.mp3car.com/vbulletin/engi...simulator.html

[cgalpin]

Yup. I haven't tried it yet but it certainly looks like a good start!

[red_parchel]

Quote: Originally Posted by kev000

Audio prioritization
Moblin has a project they call "Audio Manager". For nGhost3 we were going to write a simpler version of the same thing. It makes sure that the sound device isn't going to be used at the time by other apps. Whatever backed we chose for audio playback, it must be able to tie in with this system.

kev000, isn't this what dmix [and the like] are for? I'm sure someone much smarter than I has a reason for this "prioritization" i just don't see it right now.

UNLESS what you mean is one source will have priority over others .. so if music were playing and the GPS software wanted to say something it would mute the music play the gps sound then unmute the music [or phone call or traffic alert or if KITT wanted to say something witty] .. well through posting this i think i got the idea of what you're trying to do, I could just delete this post but a) i already typed it and b) maybe some one else will be confused like I was and this will help.

[kev000]

Quote: Originally Posted by red_parchel

kev000, isn't this what dmix [and the like] are for? I'm sure someone much smarter than I has a reason for this "prioritization" i just don't see it right now.

UNLESS what you mean is one source will have priority over others .. so if music were playing and the GPS software wanted to say something it would mute the music play the gps sound then unmute the music [or phone call or traffic alert or if KITT wanted to say something witty] .. well through posting this i think i got the idea of what you're trying to do, I could just delete this post but a) i already typed it and b) maybe some one else will be confused like I was and this will help.

Yep, that's exactly what I mean

[chunkyks]

I know I'm a bit late to this particular party, but I thought I'd throw in a couple thoughts:

Poor man's dynamic web page: For simple dynamic webpages, you could always do a poor man's version. Instead of a php daemon, you could have the component pieces dropping xml/JSON/flat text/etc files onto the filesystem, directly inside the webspace. Then have your html client software just refreshing as fast as you need.
eg, it would be possible to write a small gpsd client program that runs and dumps your current position to a three-line flat text file every second. A client could just reload that file regularly and show the contents appropriately. Another daemon program could grab dbus spam from obdgpslogger and write obd status files to disk.

It would be good, of course, to have a common standard amongst all these ... "daemonlets" for want of a word. But it's a thought.


OBD Simulators: Malcolm's obd simulator has put a bunch of ideas in my head. I'm strongly inclined to write an obd simulator that molests the pseudo serial ports like he does, except instead of pulling data from the GUI dials, it would pull it from an OBDGPSLogger log. Another difference between malcolm's and mine is that I'd be doing a command-line-only flavor, and using straight C instead of C++. This is just an idea that's been festering for a week or two. There'd be huge code duplication though, I suspect, so I'm not quite sure.


Sheeva: I can't afford one at the moment, but I did briefly experiment with the devkit earlier today. I've written instructions here: http://www.mp3car.com/vbulletin/obdi...processor.html on how to cross-compile obdgpslogger to run on the sheeva.


DBus: OBDGPSLogger does support dbus [thanks to a bit of harassment from tripzero], and signals across the SYSTEM dbus.

DBus explicitly isn't intended to be particularly network-friendly.


That's a brief braindump, apologies for any incoherence.

Gary (-;

[PaulF]

Gary, input is always welcome at any point in time.

Flat text files are a hacky solution due to read/write access of the file. If the file is locked and you try to write it, it fails and vice versa.

Also, with flat files, you lose your ability to send data back to the server/request specific information. For example, you would never be able to tell the fusion brain to turn on output 4.

PHP is the easiest language out there, why not use it? Oh and you said PHP daemon. We ditched the PHP daemon idea. Theres just a php script that gets loaded every time information is requested and it loads the appropriate classes for collecting the information.

In other words, if I loaded the page http://sheeva/request.php?fetch=GPS.Coords
request.php would load the GPS class in PHP and get the coords.
Then the following would be sent back to the browser:
GPS.Coords.lat=54.26;
GPS.Coords.long =49.28;

The JavaScript on the browser side would then pass that on to the appropriate javascript objects for handling and they would take care of shooting it over to the web browser. Easy enough to code when I have a few hours and a linux box in front of me.

[chunkyks]

That makes sense. I mean, I know flat text blows, but it's an easy way to prototype :-)

One of the problems is that OBD isn't speedy; there's no way to immediately and obviously say "I want the status of the RPM, throttle, vss, temperature, etc etc" and not have it take a long time without some sort of caching or something.

This is kinda where I pimp myself a bit, but if you're using obdgpslogger, you could connect to the database and "SELECT * FROM obd ORDER BY time DESC LIMIT 1"

Although I think there's an issue with busy locking and the like right now.

Gary (-;

[cgalpin]

obdgpslogger could accept connections on a port and report the last values it received if it just caches a little....Think gpsd.