Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Anybody need any work?
#1
We are coming up on 4.2. I always prefer to leave things alone for a bit after a release, so that if issues come up (and they often do because all the folks that come on board after it's out will generally have different conditions and catch something not caught during the beta phase.) That gives me a chance to do small patches and fixes without splitting code base.

So I'll have some time to do some customization or drivers or or images or whatnot if anyone needs any.
Dean Roddey
Explorans limites defectum
Reply
#2
Any chance of making a CQC driver to allow it to communicate with windows messages? Smile
Reply
#3
In what way exactly? In one respect of course the App Control Server does this. Are you talking about the other way around or something perhaps?
Dean Roddey
Explorans limites defectum
Reply
#4
Dean Roddey Wrote:In what way exactly? In one respect of course the App Control Server does this. Are you talking about the other way around or something perhaps?

I just need a way to communicate with CQC on a single machine.
Being on the same machine I can't rely on tcp/udp comms so... how can I 'feed' CQC and the other way around?
I want it for two reasons: to be able to use the eventghost driver and to be able to update my knx program to interact with CQC.

It doesn't have to be windows messages. I am open to suggestions Smile
Reply
#5
I fixed the Eventghost driver and wrote a new EventGhost plugin just for CQC, so you can run it on the same machine now. However interaction with windows message events would be a nice thing to have....
Wuench
My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
Reply
#6
wuench Wrote:I fixed the Eventghost driver and wrote a new EventGhost plugin just for CQC, so you can run it on the same machine now. However interaction with windows message events would be a nice thing to have....

Wow!

Finally I can try to go for a fully automated installation.

Thanks, wuench.
Reply
#7
Dean Roddey Wrote:We are coming up on 4.2. I always prefer to leave things alone for a bit after a release, so that if issues come up (and they often do because all the folks that come on board after it's out will generally have different conditions and catch something not caught during the beta phase.) That gives me a chance to do small patches and fixes without splitting code base.

So I'll have some time to do some customization or drivers or or images or whatnot if anyone needs any.

Dean: I'm interested in developing a Zigbee based driver to run a few RCS thermostats. The basic driver commands follow much of the RCS 485 Serial driver in the system pack and are run via comm ports as in that protocol, but now I (we, err, perhaps you Wink need to assemble a hex based command/response parsing of Zigbee API packets. I have communicated with the thermostats by manually assembling hex packets with checksums, etc using Digi's packet maker ftp://ftp1.digi.com/support/utilities/di...frames.htm. I have a little work to do to completely understand the packet structure (90% there), but the rest should be relatively straight forward.

The Zigbee devices with the thermostats are Digi Xbee Pro S2B 2.4 GHZ radios running API Mode 1 as Zigbee routers. I pulled a radio from another unit, and used a Sparkfun USB explorer board for a serial interface to configure it as an API Coordinator. This would be the setup to run the system, or perhaps via a USB dongle. I have done a LOT of playing with these in the past few weeks after acquiring a few off of Ebay. I contacted the seller who has around 200 of these units sitting around, and if we develop a driver he could offer them at a VERY good price to anyone interested here (I have no commercial interested in this, nor receiving compensation. Just passing along a good technology and a deal to others here.

So far they work pretty slick and I can run each thermostat independently by designating their 64 bit address, 16 bit network address. They respond to status polling commands as per the RCS protocol, but do communicate asynchronously when status changes occur (change in ambient temp, or keypad presses). These I don't need to capture, as the polling events will pick that up.

I've modified a CML driver or two here, but this might be slightly above my CML pay grade. Please PM me with your thoughts regarding. I have no idea of the cost to develop, so please be kind Wink.

Cheers,

Bugman
Reply
#8
I'm not sure I understand it. Is there some sort of comm port to Zigbee translation driver involved or something so that the driver would think it's talking to a comm port?
Dean Roddey
Explorans limites defectum
Reply
#9
Dean Roddey Wrote:I'm not sure I understand it. Is there some sort of comm port to Zigbee translation driver involved or something so that the driver would think it's talking to a comm port?

The USB board that the zigbee mounts upon https://www.sparkfun.com/products/8687 has a FTDI chip that serves to translate info from the Zigbee RF module to the RS-232 port. The USB Explorer board to the PC just looks like a USB serial converted comm port. Nothing the driver needs to do but select a comm port just like the RCS driver currently does....seemless. That's the great thing about the zigbee stuff using these little boards.
Reply
#10
Once you get the protocol figured out, post the info and I can look at it and figure out what level of effort is required.
Dean Roddey
Explorans limites defectum
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)