Domotiga in a backend/frontend setup ??

Post by **prensel** » Tue Nov 10, 2009 11:23 pm

Hello,

I'm thinking of creating a backend/frontend version of domotiga.
The backend will run (silently) as a daemon and fire all scheduled events read from the database and act on actions whereas the frontend will just modify the database.
What would it take to create the backend ? I'm thinking of stripping out the forms and all references to it, just leave in the logging options, the timers and database routines.
The frontend part would then do everything except running the timers and not run events or act on actions.
What do you think about this, anybody have another idea ??

Regards,
Paul

Post by **Alexander** » Tue Nov 10, 2009 11:30 pm

Why would you want this?

Alexander

Post by **j.hoekstra** » Tue Nov 10, 2009 11:32 pm

Why not talk to Ron about this, he would love the help with it. Besides, this is on his to-do list iirc.
I'd really like this feature as well, on the longer term I'm planning on making my server head-less(as in: no monitor, no DE)

Post by **Rene** » Wed Nov 11, 2009 12:02 am

A better solution is to separate the GUI from domotiga. Preferably by creating a webbased GUI.

Rene.

Post by **Snelvuur** » Wed Nov 11, 2009 12:22 am

Ron already made a part where he has a web frontend. I think that what others would want is to just run a "daemon" with a frontend, removing the need for a xserver environment.

// Erik (binkey.nl)

Post by **RDNZL** » Wed Nov 11, 2009 9:28 am

If me make it a daemon, a WebGUI is also needed.
Not only for the switching and devices, but also for the settings.
A bit like Homeseer.

I will try to make a CLI only DomotiGa today/tomorrow.
It only involves removing all the F<name> modules, and references to them.
And moving the start-up code from FMain and FSplashScreen to Main.module.

Anyone know a nice Ajax/PHP framework to build the webgui with?

I have looked at Extjs-3, but maybe that's overkill.

Regards,
Ron.

Post by **Rene** » Wed Nov 11, 2009 9:55 am

jquery

Rene.

Post by **mgb** » Wed Nov 11, 2009 10:04 am

Extjs works very well and is fast. License structure might be a problem though. Anyway, I like the setup of a frontend backend setup. Would be great if we could use a small linux router as the backend instead of a full blown server.

Michael

Post by **Alexander** » Wed Nov 11, 2009 11:05 am

If i may suggest: The communication between backend en frontend with XML (webservices). Everybody can than create their own frontend (windows/linux/webgui).

Alexander

Post by **RDNZL** » Wed Nov 11, 2009 11:07 am

I try to get a basic CLI/daemon version working to determine the needed
Gambas dependecies, even without the X/Gnome/GTK stuff they could be that big that it doesn't fit on a small router.
The current version should compile on ARM architecture, so that's a plus.
I have also received requests to make DomotiGa work on a NAS like the QNAP, so we tackle that too if we succeed.

Regards,
Ron

Post by **prensel** » Wed Nov 11, 2009 11:22 am

Well I did make a quick and dirty stripped version of domotiga last night, removed all the F's and references. I did stumble into some strange ' error coded stuff' like sending something to the logfile before creating the logfile....

. For now i'll wait for Ron because he's the maintainer for Domotiga but i like the way this is going in having a CLI/Daemonized version of the backend (call it DomoSched or something like that) and the X frontend. Stepping up/down to a webbased frontend wouldnt be too hard afterwards i guess.

Post by **RDNZL** » Wed Nov 11, 2009 11:36 am

That's the part I worry about, I think Gambas cli projects are not that event driven as GUI projects are (because Qt/Gtk is used for this), so it may not be possible to do it.
The error you got is probably a hint in this direction, but hopefully some missing start-up code from FMain/FSplashscreen is the real reason, which give some hope.

If I can get it to work, I probably don't build a X interface as client (with xmlrpc), only a html/ajax/xmlrpc based one (also for settings etc).
And keep the GUI version as a separate project for the standalone install needs.

Regards,
Ron.

Post by **prensel** » Wed Nov 11, 2009 12:26 pm

For the error: As far as i can see it is just some missing or misplaced code, i did rearrange the logging and now it was solved.

I also did some cleanup on the interface setting part, after the btnSave_click() in each interface setup i added the FMain.UpdateStatusPanel(). In the FMain.UpdateStatusPanel() I added a 'TRUE' check for Main.bCTX35Enabled (for example) and made the companying FMain.MenuToolsX10Cmdr.Enabled = TRUE. This way you can only active the commanders in the Tools menu depending on your enabled interfaces. Idea behind this is why have the commander control if you dont have the interface...

Post by **RDNZL** » Wed Nov 11, 2009 12:55 pm

I have got a command line version coded and running here too just now, now stressing it with all the data and interface types I have.

The web client is working with it, and I get incoming RFXCom, Digitemp, HDDTemp and ZWave data into the database.

Seems ok so far. [:o)]
Was a lot less work that I thought it would be.

Regards,
Ron.

Post by **prensel** » Wed Nov 11, 2009 2:55 pm

Great work Ron !!

I'd like to test it on the EIB interface when possible.