I FIGURED OUT HOW TO SEND STATE INFO!!!!!!!!!!!!!!!!!!

[ddamron]

Well, sort of...

The TRICK is to send COMMAND 184 (SetLevel) to YOURSELF (the device you want to set the level of)

It seems as this does acomplish the task.. but there are a few GOTCHAS

First, is Infinate Looping... if a device's command sends the SAME device the SAME command, we have an infinate loop...

Second, By sending this command, you're actually TELLING the device to go ON to that level... Not really a problem

THIRD, Sending an OFF command (193) does NOT change the STATE.. I've been able to have a state of 'OFF/100' or 'OFF/50'


I've been fighting with this problem since day one..  I guess the more you learn about a system, the more it makes sense...lol

YAY ME!!!

Dan

[MrNiceGuy]

Great work Dan!

[mchapman]

I've been following your progress..and I must tell you it fascinates me. I go to bed at night, only to wake up and find that you've delivered more code. Your the Santa Code!!

[ddamron]

Thanks guys!

I do enjoy coding...

Half the battle is figuring out HOW to do something...
The other half is actually DOING it.

I've received a few comments on people following my coding..
I think I'm going to start a thread in the Users section to see exactly HOW MANY people are following INSTEON development...

 

Dan

[PeteK]

So does this change the light display on the orbiter? I'm wondering if a better long-term solution might be to generate an event rather than a command.  The lighting module should then repsond to that event in order to change the light level displayed on the orbiters.  Right now, unfortunately, the only levels displayed are on/off.

[ddamron]

Yes, that is true, ON and OFF are the only DISPLAYED events in the orbiter.
However, by issuing this command, we can see the status on the admin site (Automation/Device Status)

More important, we can query the system as to what the current REALLY is, (vs just ON/OFF)

This trick is more of a work around, and I agree, it's not the 'right' way to do it..

My position is: it's better than just on/off, and I haven't found a BETTER way yet short of saving the light state as a devdata in the device. (and that's just a waste of programming, as it has NO LINK whatsoever to the rest of the system.. totally proprietary, just plain sloppy)

When they (whomever THEY are) DO fix the lighting to report PROPER state, they'll most likely use the value currently stored STATE...
Maybe they will add an event to change it at that time... until then, this works.

I wish I was a better programmer.. I wish I knew C++, I wish I wish I wish...

who knows, maybe I'll get pissed off at that enough to tackle it too... lol

Let's take that another step, and extend the STATE information to ALL HA devices... not just lights, but timers, Flow regulators, Curtains, Blinds, Temperature, Electrical usage, plumbing fixtures, Heat loss ratio, water temperature, etc etc etc...

I could see some SERIOUS automation going on there... this is just the tip of the iceberg!

Imagine, a house that is 'self aware' enough to try to conserve energy... to the point of dimming lights when current usage is high.. not allowing the dish washer or washer/dryer to run until current energy conditions are low enough...

add to that what lmce already is,  that is my definition of COOL.

Just some thoughts...

Dan

[ddamron]

So does this change the light display on the orbiter? I'm wondering if a better long-term solution might be to generate an event rather than a command.  The lighting module should then repsond to that event in order to change the light level displayed on the orbiters.  Right now, unfortunately, the only levels displayed are on/off.

Hey Petek!  I figured something else out!
If you view the floorplan as TEXT (not images) it DOES show the state information...
it doesn't UPDATE it until you leave and come back.. but it DOES show it..

Also, ON/OFF vs SetLevel seem to be SEPERATE COMMANDS!
even though Setlevel 'turns on' a device, internally, the DCE considers it still in the OFF state.

Can you verify the Zwave driver actually sends TWO commands? an ON command and a SetLevel?  also, what order do they send it in?

SWEET!

Dan

[bulek]

Hi,

to be consistent, I think it's best way to think about adding set level event...

There is one major flaw with orbiter lights - they are actually switches - that mean they will go into desired state after some short timeout regardless of actual state of device... I've done it in slightly different manner, state change propagate to automation and then when change is detected in lmce, proper event is sent, so device on floorplan changes it's state according to that (although it has already changed state cause of "switch" operration)....

So we need also another set of proper light devices with different logic as current light "switches"...

There is also a lot of work to be done to increase support for more devices that can be shown on floorplan. Currently we don't have generic output device with ON/OFF that could be shown on other floorplans beside lighting...

Regards,

Bulek.

[ddamron]

Hi,

to be consistent, I think it's best way to think about adding set level event...

There is one major flaw with orbiter lights - they are actually switches - that mean they will go into desired state after some short timeout regardless of actual state of device... I've done it in slightly different manner, state change propagate to automation and then when change is detected in lmce, proper event is sent, so device on floorplan changes it's state according to that (although it has already changed state cause of "switch" operration)....

So we need also another set of proper light devices with different logic as current light "switches"...

There is also a lot of work to be done to increase support for more devices that can be shown on floorplan. Currently we don't have generic output device with ON/OFF that could be shown on other floorplans beside lighting...

Regards,

Bulek.

Bulek,

As I mentioned, I agree..
This is only a work around.. since no event currently exists.

I'd like to add/increase support for the floorplans, but as of yet, I don't know enough.

Excellent comments!

Dan

[totallymaxed]

Yes, that is true, ON and OFF are the only DISPLAYED events in the orbiter.
However, by issuing this command, we can see the status on the admin site (Automation/Device Status)

More important, we can query the system as to what the current REALLY is, (vs just ON/OFF)

This trick is more of a work around, and I agree, it's not the 'right' way to do it..

My position is: it's better than just on/off, and I haven't found a BETTER way yet short of saving the light state as a devdata in the device. (and that's just a waste of programming, as it has NO LINK whatsoever to the rest of the system.. totally proprietary, just plain sloppy)

When they (whomever THEY are) DO fix the lighting to report PROPER state, they'll most likely use the value currently stored STATE...
Maybe they will add an event to change it at that time... until then, this works.

I wish I was a better programmer.. I wish I knew C++, I wish I wish I wish...

who knows, maybe I'll get pissed off at that enough to tackle it too... lol

Let's take that another step, and extend the STATE information to ALL HA devices... not just lights, but timers, Flow regulators, Curtains, Blinds, Temperature, Electrical usage, plumbing fixtures, Heat loss ratio, water temperature, etc etc etc...

I could see some SERIOUS automation going on there... this is just the tip of the iceberg!

Imagine, a house that is 'self aware' enough to try to conserve energy... to the point of dimming lights when current usage is high.. not allowing the dish washer or washer/dryer to run until current energy conditions are low enough...

add to that what lmce already is,  that is my definition of COOL.

Just some thoughts...

Dan

One of the many things we need to improve is the way we make information about the internal workings of LinuxMCE more accessible to you guys (and other groups here inside the community). Often the problem is that the docs just do not exist, other times its because they do not exist in a format that can be easily distributed and then sometimes whats needed is access to someone who has a 'map' inside his/her head about how LinuxMCE works 'under the hood'. The other problem is we have to draw this information from numerous sources... primarily  WebPaul, the Pluto dev team and contributing companies like mine.

All I can say is that there is work underway to make all this happen and you guys should start to see the benefit of this soon. In the meantime I will try to connect you guys with the information/support you need on an ad-hoc basis until we have a more formalised mechanism in place.

Andrew

[tschak909]

ddamron, just know man.. you're not alone.. I'm down in the trenches with you trying to work on my new media plugin (when my health permits).

let's make this system _the_ system.

make Crestron and AMX green with envy.

make the HomeSeer users realise they're a little short

make the rich bastards who spent hundreds of thousands on ultra custom solutions no-one can maintain drop their jaws.



-Thom

[ddamron]

Thom,
Isn't this system that already!?? lol

I know you're Here with me... you stepped on me the last time you climbed out.. 

All joking aside.. I owe you a huge 'addaboy!'