Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - david_a_dawson

Pages: 1 2 3 [4] 5 6
Users / Re: Insteon versus XX for lighting.
« on: November 25, 2011, 09:05:11 pm »
This is asked quite often, and the routine answer seems to be: for new installations go with the KNX/EIB, for retrofitting the Z-wave gang. See for example,12141.0.html and others. For most other systems, please pay attention to the reliability. It just doesn't make any sense to play with stuff that you cannot rely on. Waveman, I have had my share of problems with that. Still in the process of getting rid of the rest modules.

Powering up/down the whole house, sound wild, and requires some high amp relays. So you don't have anything that should be left on all the time?


Thanks for the info.  I'll have a look at the suggestions.

Its not so much as a requirement as a simplification of adding power control on the various appliances. 
I'm planning to extend our installation out to be a fair sized one, and so it'd be really nice to be able to shut off portions of the house, eg floors or lighting (or the shed, or garage) by just switching off the ring main that supplies it.  Not totally necessary, I'm sure that it could be sorted somehow.
I was looking round the other day at all the things that we leave switched on, and there really isn't that much that needs it.   Eg, the microwave wants power all the time to keep its clock up to date.  Well, I have a clock on the wall, I really don't need it to be a second clock.  OTOH, I don't want to be manually switching it on whenever I want it.  So, some kind of automation around me being near it is the ideal.

My base power draw is around 700 watts, all the time.  I think that if we can selectively power down portions of the electrics, then this will be drastically reduced; so making the LMCE installation pay for itself (although this isn't the goal).

One long term goal I have in mind would be to be able to put the house into a mode where just the core, maybe lights and also the security system is active; the power to the main power circuits (or some, eg downstairs) is shut off, and is only engaged if the motion detectors trip.  So you could power the main electrics down unless someone started wandering around the house, at which point things fire up (thinking my little confused children here).

Similar if we go away, I'd like to just leave the core and the security switched on.  Then maybe have the lights be powered up every night or something to scare away the burglars, but have power usage be really minimal at the touch of a button.
All seems possible with the magical thing that is lmce, I just have to get the right hardware and configure it all up.


Developers / Re: qOrbiter build
« on: November 25, 2011, 01:43:55 pm »
Yep, that works perfectly for me.

Users / Insteon versus XX for lighting.
« on: November 25, 2011, 12:34:26 pm »

I'm looking to do some lighting automation.

Which system would be recommended for best integration with lmce?   
I've seen people pushing insteon online as a better alternative to X10, but then there's the others around.

I'm in the UK, looking for  :-

  • Cheap
  • On/ Off plus dimming
  • Mains lights
  • Socketed lights (table lamps and the like)

Also, does anyone know of automated switches/ solutions that can power down an entire ring main?

I ask as I'm interested in putting the core on its own line off the meter and then be able to power up/ down the whole house remotely.

Sound feasible?


Developers / Re: qOrbiter build
« on: November 22, 2011, 06:30:26 pm »
No worries, we need folks to take a look at my superbad qml to look for ways to improve it / abstract things so that multiple skins can interact effectively. Currently, the skinning engine seems to be holding up, but im sure there is room for improvement. My recommendation would be to play around with qml and get to know it. There is still the rather large task of documenting the skinning api so that we can provide skin designers with an document that shows the various functions available and how to interact with them.


Grand.  I've got thursday/ friday mostly free this week, so I'll spend some time then do that.


Developers / Re: qOrbiter build
« on: November 22, 2011, 05:56:30 pm »
Which part are you looking to work on? There is lots of c++ work to do and  lots of design work to do to finish the screens. Any particular part you were interested in contributing to?


I do web based dev in my day job, java on the server and lots of javascript type stuff on the clients (including a fair amount of GUI design)

My C++ is pretty ropey, I think I'd just cause problems, but I'm willing to help out there if its wanted (probably as QA/ tester)

I'm probably best off looking into the QML/ design aspects I think.

I can probably do some system tech documentation as well if you'd like (I can read C++ well enough for that)


Developers / Re: qOrbiter build
« on: November 22, 2011, 03:10:03 pm »
After a little play, the UI is much prettier!  Even he UI1-alike is nice, clean and usable (the text fits in the boxes!!)

So, where is best to start looking to contribute to this?


Developers / Re: qOrbiter build
« on: November 22, 2011, 02:11:51 pm »
Working now.  here is what i needed
  • fresh install of kubuntu 10.04 in a VM (32 bit)
  • Fresh SVN (no updates needed)
  • Fresh download of QT Creator (32 bit) with QT 4.7.4

So, I'm running it in a VM.  Not ideal, but hey ho.

The core is currently generating screens for it.  I thought this would no longer be necessary?  Or is that my mistake?

It'd be cool if the whole orbiter generation thing wasn't needed any more, just be told the layout and render it on the device.


Developers / qOrbiter build
« on: November 22, 2011, 12:51:05 am »

I'm trying to get a clean build for the qOrbiter using qt creator.

I'm pretty sure I'm doing something silly, my C++ is not great.

I'm on 64 bit ubuntu 11.10.  I've downloaded the latest source (following the wiki page), generated the device and set up QT Creator as in the wiki.

I've selected the 'for_desktop' config.
I've tried with QT (64 bit shipped with QT Creator) 4.7.4 and 4.8.0 with the same result.

On build/ Run, I then get a compile error in DataGrid.cpp.

../../DCE/DataGrid.cpp: In constructor ‘DCE::DataGridTable::DataGridTable()’:
../../DCE/DataGrid.cpp:336:26: error: cannot call constructor ‘DCE::Message::Message’ directly [-fpermissive]
../../DCE/DataGrid.cpp:336:26: error:   for a function-style cast, remove the redundant ‘::Message’ [-fpermissive]
make: *** [DataGrid.o] Error 1

Commenting that line lets me proceed a little further, whereupon I get :-

/usr/bin/ld: qorbitermanager.o: undefined reference to symbol 'QAbstractSocket::isValid() const'
make: Leaving directory `/home/david/Development/Source/opensource/linuxmce1004/src/qOrbiter/build-output'
/usr/bin/ld: note: 'QAbstractSocket::isValid() const' is defined in DSO /home/david/Apps/QtSDK/Desktop/Qt/4.8.0/gcc/lib/ so try adding it to the linker command line
/home/david/Apps/QtSDK/Desktop/Qt/4.8.0/gcc/lib/ could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [qOrbiter] Error 1
The process "/usr/bin/make" exited with code 2.
Error while building project qOrbiter_src (target: Desktop)
When executing build step 'Make'

Any ideas?

If its the 64bitness, I might have to investigate running 32bit versions of the qt libs.



Wiki / Re: Link Spamming warning
« on: November 13, 2011, 11:41:27 pm »

Works now.  I've added the edit in.

Wiki / Re: Link Spamming warning
« on: November 11, 2011, 04:31:21 pm »
Hmm.  I wasn't trying to add a link.

There was an IP address in there, but no links of any kind  :-(

Wiki / Link Spamming warning
« on: November 11, 2011, 12:31:35 pm »

I've been installing a core into virtual box and I thought I'd include updated network settings based on my (seemingly successful) configuration in virtual box on the wiki page.

I've tried updating the page, however it keeps on telling me that I'm link spamming and to contact an admin.

So here I am!


Developers / Re: Orbiter UI Elements/ HA Designer
« on: November 11, 2011, 01:48:46 am »

I was totally misled by the naming.  QML is a Javascript derivative.  I hadn't realised at all I'd assumed it was some bastardised xml dialect.

I can certainly help with this, I do javascript UI's (web/ mobile) every day alongside enterprise Java. which is probably less useful here... ;-)

Currently setting up a core for development on virtualbox, and its not playing nice. Also got qt creater & co installed and all the project open.

Maybe a fresh look tomorrow will help.


Developers / Re: Orbiter UI Elements/ HA Designer
« on: November 11, 2011, 12:41:01 am »
Thanks for the quick reply!

All sounds very good to me.   

If I were to create a new device that required an Orbiter UI.  How would that be achieved?   

Would the Orbiter UI for that device have to be included in every skin?  or is there a way to create the UI just the once?

If it needs to be implemented in every skin, well, that's still fair enough; I can see that the other benefits of the QML approach far outweigh any other considerations.

I'm considering making a new device that might need a fairly comprehensive UI and I'm trying to scope it out a bit.


Developers / Orbiter UI Elements/ HA Designer
« on: November 11, 2011, 12:01:30 am »

I see the comprehensive series of screen casts for creating new bits of Orbiter UI.

I was wondering, will they still be valid for the qOrbiter when its finished (looking very slick now..)?

Sorry if this is a silly question, just checking that the underlying data is being altered at all.



Developers / Re: QOrbiter: Something for everyone!
« on: November 10, 2011, 01:20:39 am »
screw droid!!! omfg it has been harder to get it running on a droid device than learning how to make Qorbiter!!!!

but seriously, its slowly killing me inside haha. Never the less, im up to the part where im trying to get it to change screens and am trying to figure out what works because...yeah. It has a lotta 'gotchas'.

Thanks for the vote of confidence Purps!

How's this going?  I'd be happy to do some testing for you on android phone or tablet if you're up to that stage/ it'd help.

Pages: 1 2 3 [4] 5 6