Agreed.

If you really are stuck, do a wiki search for some of my code.
Insteon, PLCBUS, and ThreadedRuby.

All of those implement Lighting.

Good Luck.

Dan

We had that working at LinuxTAG last year, if I recall......

Dan

Also, there's 1 wire devices that are allready implemented.  If you need Temp sensors, etc.

(I'm just brainstorming here)

Dan

Thanks for the great reply. And yes, the PP is certainly already dead. If it were not for some amount of legacy stuff there would ultimately be more USB connections in that space.

Any port would work just as well.

What I am looking at is using something like a Motorola MCH6811 type of MC as a front end to effectively integrate anything.

Thinking that one only because I have one and have done a reasonable amount of MASM programming.

Are there other options with other ports for more low level communication? Not sure about the MCH for interpretation of high level, but if I need to pursue different MC not a big deal either.

I don't have a specific application in mind, and acknowledge a lot of home automation is now readily available through Zwave enabled devices. Just trying to understand potential capabilities. I don't need to do it today.

Craptastic

There's a ton of good stuff on microchip.com if you like low level...
Very affordable ICSP (serial programming), programming PICs are a snap.

Hope that helps

Dan

umm, direct communication via port... ie 378H or 3BCH, depending on how you have your pp configured.
I've done a ton of that, pretty simple, write to the port, and read it back

Okee Dokee, will try tonight, and report back.

Update:  attempted again, now I can't install it,

I get: 904 JAR size mismatch
jar size does not match MIDlet-Jar-Size attribute

Getting closer, I can feel it in my bones

HTH,

Dan

Hi Thom, I'm trying to get up to speed again.

I'll help where I can.

Dan

Hi Guys!

I'm trying to get back into the swing of things here..
I have had Hari's version running on my blackberry 8330 Curve, it's amazing what upgrading the OS will give you

Sambuca:  I tried to get your version working, maybe I'm missing something, it installed fine over the web..
when I attempt to start it, I get:

Error starting JavaMO:
Symbol 'CommandListener.SELECT_COMMAND' not found

any ideas?
Phone is midp2.0/CLDC1.1/JSR082 (Hari's version worked for about 2 keypresses)

Thanks in advance!  Glad someone picked this project up!

All the best,

Dan

+1

Hi guys.

Quick note:  look up the PLCBUS code in the wiki:
That code has all my ThreadedRuby (I didn't find out until AFTER I coded it that PLCBUS can't handle threaded messages :/)
I did comment the code, and it's a bit alpha-ish, but that might help.

Bulek, a note for your if-then-else,
the threadedruby code is designed so you can put all your protocol dependant code in a seperate object.  because of this, there are certain parts you need to implement:
eg: sending a command to insteon, here's the steps:
First, each command is an object consisting of a complete structure of data, and flags.

threadedruby intercepts the message from DCE
checks to see if its a response the other way around (eg: a command originating from GSD)
when it does this, it passes the message to the device's object (to determine if it's a proper response)
if not, it moves on to the next command object, etc, etc.
if all that failes, (eg: it's not a proper response to any existing messages) then it creates a new command object, sets the direction, etc, and queues the command for transmission.

The nice thing about threadedruby is that the code for processing data is the same in both directions, ie DCE->GSD, and GSD->DCE.
Both GSD and DCE have data to return to each other, and may not be particularly sync'ed up.

The goal of threadedruby was to allow multiple commands/responses to and from GSD/DCE.
ThreadedRuby tracks all messages for you.


http://wiki.linuxmce.org/index.php/PLCBUScmd373 (this has all the details)
http://wiki.linuxmce.org/index.php/PLCBUS (this has all the rest)


Best holiday wishes to all!

Dan

PS,
Sorry I haven't been around much lately, I've got other issues to deal with atm.

Heh, thanks Thom, I wish I was there too!!

Bulek,
Yes, you are correct, ideally, there should be a state changed event (to correspond to DCE philosophy) and a param to adjust state.  In my case, my driver needed to change the state of a child device. 

I would like to see a param value that we can use to read and write the state of a device.
Initially, when I wrote my driver, I had no way of reading and writing state.  My solution (albeit a work around) was to WRITE the state via (send cmd to self) and then track the state inside my driver.

HTH,

Dan

Jon,

We can accomplish this via programming atm, if we are careful...
1.  simply program last state information into the shutdown code for each device...

2.  Read the last state info and set accordingly, maybe repoll if needed,

in Ruby, there is a Shutdown command, where we can gracefully shutdown our devices

also, there is a command "Add/Create Devdata", where we can programmatically 'ADD' the device's state AS device data,
and use that for persistence.  That is how I poll and store each Insteon device's complete database.
(Consequently, that one took me about 2 weeks to figure out)

HTH,

Dan



 

yeah, webadmin

or more specifically, the Advanced (at the top), DCE, then you choose:
Commands,
Events,
Device Data

from there it should be pretty self explanatory

BTW, thanks for waking this thread up, I've been meaning to get to a DCE webcast, and this kinda poked me into that direction

All the best,

Dan

well, it's been a long time since I've seen this thread...

of the top of my head, and scanning the DCE Commands, there's a command to do it.
cmd[68] Get Device Data
cmd.params[2] = deviceID
cmd.params[52] = devicedata you want to retrieve
cmd.params[53] = false
sendcommand
name is returned in cmd.params[5]

that should do it!
wow, i must have learned something, that was only a 2 minute solution,
cool!

regards,

Dan