Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
CQC controlling Model Railroad???
#31
Deane's son Mike, here.  I've been following with great interest all of your ideas and comments.  Thank you.  Now that I've gotten my forum account activated, I can join the conversation.

I'm very new to the Arduino, but have been trying to learn as much as I can about it.  I still don't know a lot, but it's starting to come together.  To answer your last question, Dean, it appears as though it is just a microprocessor, not a computer.  The way it works is you write a script (they call it a sketch), upload it to the Arduino device (there are several types), and it loops through the sketch continuously.  There are many libraries available for specific tasks.  For example, the servo library is called when anything related to a servo is needed.  For this discussion, I've learned how to control the servo, setting end points and the speed at which the servo moves (technically, the standard servo library won't do that, so I found another one that does).  I have a switch that sets the servo at either end of its travel, based on a PWM value.  This is the perfect control operation for the railroad turnouts.  When the switch is thrown, the servo moves at the predetermined speed to its endpoint location.

But physical switches on a panel are old school model railroading.  Enter the iPad.  Since Dad is already heavily into HA with the iPad, and CQC's touch screen designer is very capable, I thought it would be a perfect match.  In addition, automated tasks could be moved to whichever platform makes the most sense, Arduino or CQC, and, of course, interaction between things like room lighting and the railroad operation are easy.

Of course, connecting CQC to Arduino is our current stumbling block.  Since the CQC Arduino driver called for an Ethernet connection, instead of the normal USB connection, we started down that path.  An addon board supplies the hardware for Ethernet.  As I'm learning now, it doesn't appear that you set the IP address of the Arduino as you would a computer, i.e., semi-permanently, but rather you set it within the Arduino sketch.

Once we write the sketch to include the setting of the IP address, we need CQC to talk to that IP address.  Then, and this is where I get lost, we need for CQC to be able to send commands to the Arduino (in their simplest form, just logic commands) that the Arduino sketch can listen for.  When a certain command is received (i.e., logic state change), the sketch executes a function.  And, on the flip side, have CQC listen for commands from Arduino to execute HA tasks or simply report status to the touch screen.

As has been pointed out, Ethernet is not required, but may have some advantages.  The normal connection between the Arduino IDE and the board is USB.  But, as far as I have been able to figure out, the Arduino IDE isn't a control interface, just a place to create sketches and upload them to the device.

So, the CQC driver would need to be able to communicate with the various pins on the Arduino (most of which can be set as inputs or outputs, some PWM, some analog).  Each pin could be connected to an individual turnout, or a pin could be used to set several turnouts to various positions to form a path for the train (similar to a HA lighting scene).  In that case, the Arduino sketch would have a function that sets the various turnouts.  Or an analog input could be used to manually set the position of a servo (a function in the sketch would be written to receive the incoming signal and translate it to the proper PWM output for the servo).

I'm sure CQC could be asked to do much more than we are presently proposing, but just getting some simple send/receive capability would be great (maybe it's already there and we just don't know how to use it?).  It could do more of the "scene" type programming, since that's what it's designed for.  Arduino no doubt duplicates things that CQC could do.  So, if the CQC driver could access and control every pin, there might not be a need for much of a sketch in the Arduino, just one to establish a connection.  Maybe that's how the Homeseer plugin works?  However, having the option would be the ultimate in flexibility.

Mike
Reply
#32
(01-12-2017, 05:34 PM)mikedj Wrote: Deane's son Mike, here.  I've been following with great interest all of your ideas and comments.  Thank you.  Now that I've gotten my forum account activated, I can join the conversation.
welcome aboard

(01-12-2017, 05:34 PM)mikedj Wrote: I'm very new to the Arduino, but have been trying to learn as much as I can about it.  I still don't know a lot, but it's starting to come together.  To answer your last question, Dean, it appears as though it is just a microprocessor, not a computer.  The way it works is you write a script (they call it a sketch), upload it to the Arduino device (there are several types), and it loops through the sketch continuously.  There are many libraries available for specific tasks.  For example, the servo library is called when anything related to a servo is needed.  For this discussion, I've learned how to control the servo, setting end points and the speed at which the servo moves (technically, the standard servo library won't do that, so I found another one that does).  I have a switch that sets the servo at either end of its travel, based on a PWM value.  This is the perfect control operation for the railroad turnouts.  When the switch is thrown, the servo moves at the predetermined speed to its endpoint location.
actually, it is more of a microcontroller...
specifically one of atmel's nifty little everything you need on a single chip microconroller... with an open source boot loader + IDE called "arduino" oddly enough...
but yea, same thing, just being picky Smile

(01-12-2017, 05:34 PM)mikedj Wrote: Once we write the sketch to include the setting of the IP address, we need CQC to talk to that IP address.  Then, and this is where I get lost, we need for CQC to be able to send commands to the Arduino (in their simplest form, just logic commands) that the Arduino sketch can listen for.  When a certain command is received (i.e., logic state change), the sketch executes a function.  And, on the flip side, have CQC listen for commands from Arduino to execute HA tasks or simply report status to the touch screen.

As has been pointed out, Ethernet is not required, but may have some advantages.  The normal connection between the Arduino IDE and the board is USB.  But, as far as I have been able to figure out, the Arduino IDE isn't a control interface, just a place to create sketches and upload them to the device.

So, the CQC driver would need to be able to communicate with the various pins on the Arduino (most of which can be set as inputs or outputs, some PWM, some analog).  Each pin could be connected to an individual turnout, or a pin could be used to set several turnouts to various positions to form a path for the train (similar to a HA lighting scene).  In that case, the Arduino sketch would have a function that sets the various turnouts.  Or an analog input could be used to manually set the position of a servo (a function in the sketch would be written to receive the incoming signal and translate it to the proper PWM output for the servo).

I'm sure CQC could be asked to do much more than we are presently proposing, but just getting some simple send/receive capability would be great (maybe it's already there and we just don't know how to use it?).  It could do more of the "scene" type programming, since that's what it's designed for.  Arduino no doubt duplicates things that CQC could do.  So, if the CQC driver could access and control every pin, there might not be a need for much of a sketch in the Arduino, just one to establish a connection.  Maybe that's how the Homeseer plugin works?  However, having the option would be the ultimate in flexibility.

Mike
that is where a driver comes in, that could be the generic one, or an application specific one, an you will need to add code to the sketch to listen to the command from CQC and execute those command, whether it is sending it to the Servo handling routine or toggling a pin... but it will be up to your sketch to handle those incoming commands from CQC, and to provide CQC a status of where everything is at so CQC can adequately reflect that on the UI...

on the CQC driver side you will probably be better off creating an application specific one I think... will make doing the UI easier at least...

you will need to tell CQC what to send, and then you will need to program the arduino to listen for that command and carry out the given task, so you could have the CQC Driver (of your own creation, it is actually fairly simple... if you can write a functioning sketch, you can write a driver) literally send a text string that says "Set Turnout #1 Left" and your sketch would be listening to the communications port, and when it sees the text "Set Turnout #1 Left" it will call whatever functions it needs to to make it happen, once it has completed, it will send a message of "Turnout #1 Left OK" (or something) back to your CQC driver... easy peasy, everything is in sync and the model railroad has been saved from the impending doom of going right...

(assuming Left/Right is the correct terminology for a Turnout?, you could write everything so you just pass back and forth a Servo ID, and the position in degrees to set it too, but Left/Right Seems so much easier from a human readable standpoint?)

anyway, hope that help, and welcome to the board (no train puns this time Smile )
NOTE: As one wise professional something once stated, I am ignorant & childish, with a mindset comparable to 9/11 troofers and wackjob conspiracy theorists. so don't take anything I say as advice...
Reply
#33
I'm pretty sure that a user here, Karenlee, has written code to run on the Arduino and talk to the existing driver. Maybe you could PM her to come kick in on this thread. I actually wrote it for her to use if memory serves.
Dean Roddey
Explorans limites defectum
Reply
#34
(01-12-2017, 07:34 PM)SomeWhatLost Wrote: actually, it is more of a microcontroller...
specifically one of atmel's nifty little everything you need on a single chip microconroller... with an open source boot loader + IDE called "arduino" oddly enough...
but yea, same thing, just being picky Smile

Yea, that's what I meant... Cool

(01-12-2017, 07:34 PM)SomeWhatLost Wrote: that is where a driver comes in, that could be the generic one, or an application specific one, an you will need to add code to the sketch to listen to the command from CQC and execute those command, whether it is sending it to the Servo handling routine or toggling a pin... but it will be up to your sketch to handle those incoming commands from CQC, and to provide CQC a status of where everything is at so CQC can adequately reflect that on the UI...

on the CQC driver side you will probably be better off creating an application specific one I think... will make doing the UI easier at least...

you will need to tell CQC what to send, and then you will need to program the arduino to listen for that command and carry out the given task, so you could have the CQC Driver (of your own creation, it is actually fairly simple... if you can write a functioning sketch, you can write a driver) literally send a text string that says "Set Turnout #1 Left" and your sketch would be listening to the communications port, and when it sees the text "Set Turnout #1 Left" it will call whatever functions it needs to to make it happen, once it has completed, it will send a message of "Turnout #1 Left OK" (or something) back to your CQC driver... easy peasy, everything is in sync and the model railroad has been saved from the impending doom of going right...

(assuming Left/Right is the correct terminology for a Turnout?, you could write everything so you just pass back and forth a Servo ID, and the position in degrees to set it too, but Left/Right Seems so much easier from a human readable standpoint?)

Yes, left and right is fine. But I was thinking the driver should be more generic (pin x, high or low, etc.), then the Arduino sketch and the CQC device get the more device specific terminology.  Forgive me if my terminology isn't accurate (I don't have CQC), but my analogy would be something like an X10 lamp.  I assume the X10 driver simply identifies the lamp as house/unit code A1.  It's up to your description of the device in CQC to become "Living Room Lamp" or whatever.  So, for the railroad example, you create a device in CQC called "turnout #1" and associate it with, say, pin 1 on the Arduino. The driver only knows it as pin 1.

That's my long-winded way of suggesting that the driver be as generic as possible so it can be used for anything Arduino.  And I assume the driver would have to come with some sample Arduino code to get things rolling.  Since Arduino pins can be set within the sketch to be input or output, there would need to be a way to communicate that to CQC.


(01-12-2017, 07:34 PM)SomeWhatLost Wrote: anyway, hope that help, and welcome to the board (no train puns this time Smile  )

Yes, it helps a great deal.  I'm still not sure I'm up to the task of writing a driver (especially since I don't have CQC!), but your thoughts and ideas have been very helpful as we explore options.  I've sent a PM to karenlee, so hopefully we can get some more info on what's already been done.

Thanks,
Mike
Reply
#35
As you guys get deeper and deeper into this, you've left me at the station. (pun intended).

Seriously, I'm following this with considerable excitement and anticipation.  Meantime, I've been trying to get a little familiar with JMRI to try and get a feel whether it or CQC would work best and easiest (or at all).  No opinion at this time.

Deane
Reply
#36
(01-13-2017, 07:16 AM)Deane Johnson Wrote: As you guys get deeper and deeper into this, you've left me at the station. (pun intended).

Seriously, I'm following this with considerable excitement and anticipation.  Meantime, I've been trying to get a little familiar with JMRI to try and get a feel whether it or CQC would work best and easiest (or at all).  No opinion at this time.

Deane

I believe you came to CQC from HS? is so, and assuming nothing has changed on the HS front in the last 5+ years, CQC drivers and JS drivers are vastly different...
for HS it at least used to be you needed a PHD in CS or a related field to create a driver (bit of an exaggeration... but still, heavy programing involved)
CQC on the other hand, all the heavy lifting is done by CQC itself, and the drivers just sort of translate (bad analogy, but it is the best I can come up with...)
CQC supports 2 types of drivers,
CML, is fairly detailed, very powerful, but does need some actual programing... and as such is somewhat scary to us non-programer types...
PDL on the other hand is actually quite simple, it is a basic text file that just defines:
  • the names of the fields that will be selectable from inside CQC (turnback #1, turnback#2, Led #1,etc)
  • the valid options for that field (left/right, up/down,on/off, a percentage, a number, etc..) assuming there are limits...
  • when CQC "Field X" changes its value to Y, send out Z to the arduino...
  • when arduino sends message A back to CQC match it with a field, and then set that field appropriately...
(note this is just my take on PDL, Dean probably has some long detailed explanation of what it does from a programmers point of view... but I like mine...)

it is all very very simple, and since PDL is just a text file, it is easy to just find an existing driver that is doing something similar and do a bit of copy/pasting...
the only real down side of PDL is its simplicity... if the device you are talking to requires more logic than what PDL provides, like needs to make choices based on responses/etc then you are stuck with CML...
but as long as you can keep it a "when I send X, I can always expect Y" simple back and forth between CQC and the arduino, PDL is great...

Mike wants to do a generic driver, and there is absolutely nothing wrong with that, perfectly valid approach to the problem, the only downside is that leaves you dealing with all the "set this to that" in the UI, not horrible, CQC is more than capable of handling that but it is somewhat messy (messy = very much just my own opinion)...

my stance is that since you control both sides of the equation, you can guarantee that the back and forth messaging between CQC and arduino fit within the realm of a PDL  driver, PDL's are simple to create, and when it comes time to create the UI, it is a simple case of set field "Turnback #1" to left, and display the current position of "Turnback #1" over here... UI is much cleaner...

neither option is necessarily right or wrong, or better than the other, all just personal preference... and I prefer my way Big Grin

(01-13-2017, 07:16 AM)Deane Johnson Wrote: As you guys get deeper and deeper into this, you've left me at the station. (pun intended).

Seriously, I'm following this with considerable excitement and anticipation.  Meantime, I've been trying to get a little familiar with JMRI to try and get a feel whether it or CQC would work best and easiest (or at all).  No opinion at this time.

Deane
as far as JMRI goes, looks like they support  external control, so you could just build a JMRI driver for CQC, and have it control JMRI, so, not really and either or choice there either Tongue
NOTE: As one wise professional something once stated, I am ignorant & childish, with a mindset comparable to 9/11 troofers and wackjob conspiracy theorists. so don't take anything I say as advice...
Reply
#37
SomeWhatLost, to be clear, I haven't used HomeSeer except to download a trial a few years ago when Elve quit and I was looking for a shelter to run to.  That's when I decided on CQC.  Son Mike (aka-mikedj) has used HomeSeer for many years.
Reply
#38
(01-13-2017, 08:25 AM)Deane Johnson Wrote: SomeWhatLost, to be clear, I haven't used HomeSeer except to download a trial a few years ago when Elve quit and I was looking for a shelter to run to.  That's when I decided on CQC.  Son Mike (aka-mikedj) has used HomeSeer for many years.

well weren't elve drivers C++ or something like that? so my unscientific observation still holds true Cool
NOTE: As one wise professional something once stated, I am ignorant & childish, with a mindset comparable to 9/11 troofers and wackjob conspiracy theorists. so don't take anything I say as advice...
Reply
#39
I have no idea what was behind the screen with Elve. I just push buttons until something happens.
Reply
#40
(01-13-2017, 08:54 AM)Deane Johnson Wrote: I have no idea what was behind the screen with Elve.  I just push buttons until something happens.

+1... that is my preferred method of operation Big Grin
NOTE: As one wise professional something once stated, I am ignorant & childish, with a mindset comparable to 9/11 troofers and wackjob conspiracy theorists. so don't take anything I say as advice...
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Controlling Insteon Scene Controller buttons ellisr63 8 5,870 10-14-2014, 11:38 AM
Last Post: SomeWhatLost
  Android Widgets directly controlling CQC! IVB 39 14,684 12-08-2013, 12:24 PM
Last Post: Dean Roddey
  Controlling ZigBee (or Z-Wave) on HAI anogee 2 2,459 12-18-2012, 12:06 PM
Last Post: Dean Roddey
  Controlling an onscreen GUI cavalier240 10 4,466 03-20-2012, 09:40 AM
Last Post: standon
  Onkyo TX NR708 Driver Model Choice jmwhooper 2 2,459 05-19-2011, 02:01 PM
Last Post: wdill
  Need help with controlling an app simon 26 10,421 11-28-2009, 01:42 PM
Last Post: sic0048
  Controlling devices that use HDMI-CEC cavalier240 4 3,229 09-26-2008, 05:25 AM
Last Post: sic0048
  CQC controlling VLC or MPlayer on Windows or Linux dkemme 2 2,283 02-25-2008, 09:49 AM
Last Post: dcpete
  Is 4s lag normal for CQC controlling CQS Audio player? Sendero 11 4,956 01-04-2008, 11:55 PM
Last Post: Dean Roddey
  controlling autopatch via rf? Providince 8 4,107 06-01-2007, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)