CM11A - adding new lights...

[ddamron]

Hey Guys:
Devicepoll.cpp Line 239, remove the '!'.
That fixes the polling! YAY

Tested and confirmed!

All the best,

Dan

Cheers Dan,

Given the code below and your change this would infer that in logical/boolean terms somewhere in the pluto code FALSE is defined as being true 

Code: [Select]

bool CSerialPort::IsReadEmpty()
{
    Sleep(0);   
    return FALSE;
}
Does anyone know where FALSE is defined as if the above is correct then it makes reading code very difficult

NOS

Yes, it does.  I'm just starting in C++ and as such didn't dig into it.  I just used logging here and there to try to find out WHY it was ignoring the 5A.
After about 4 recompiles, i found that the logic for CSerialPort::IsReadEmtpy() is reversed...  and I'm not sure (yet) of the effects of changing that code.

For now, to get you guys going, that works.  When I learn more, I'll revisit this.

All the best,

Dan

[jondecker76]

Dan - its about knocked out now - Nosilla restructured the code - it wend beyond just the IsReadEmpty()..  We will let you know when all the changes are finished (on the last part right now)

@Nosilla
Its 3:20PM right now, I leave for another long night at work at 5:00PM. Send me a message if you get on before then - I think I have the sending of events fixed. If not, I'll share it with you tomorrow.

[nosilla99]

@jondecker,

I will let you figure that one out and await your results tomorrow, as I could not think of an elegant solution so I hope you have better luck than me 

I hope you are earning good money doing 14hr shifts as it can't be healthy

Take Care

NOS

[jondecker76]

I'll share my results with you tomorrow after I wake up. I haven't fully tested it yet, but I'm quite sure it works as it should.

Also I got to thinking about the sendpacket() routine.. There are 3 cases I can see that will mess things up in its current state..
1) Sending an address where the lowByte =checksum-highByte (basically 0x56 - G1 house:unit code since the dim bits won't be set in this instance) will have an actual checksum of 0x5A
2) Sending a function where the lowByte = checksum-highByte will have an actual checksum of 0x5A(there are many situations where this could happen)
3) Sending an extended function the sum of the data bytes & 0xFF = checksum-highByte (though extended functions are not yet supported so it really isn't relavant here)

I have rewritten the logic to deal with these situations elegantly - i will share those changes with you tomorrow as well.

About work - yes, the shifts are long, but I only work 15 days each month (and the pay is great). Its a strange schedule, but I work 4 night shifts, then I'm off for 4 days, then I work 3 day shifts, then i'm off for 1 day, then I work 3 night shifts, then I'm off for 5 days, then I work 4 day shifts, then I'm off for 7 days..  then this 28 day rotation repeats forever..  just takes some getting used to!

[nosilla99]

Well spotted, once both sets of issues are resolved we should have a perfectly functioning CM11A handler.

I look forward to receiving your updates

Best Wishes

NOS

[ddamron]

Guys,

Great work going on in here..

I hope you don't mind, I'm moving this thread over to the Development area.

Keep up the great work!

Dan

[nosilla99]

@ddamron

Thanks for the support, and  I thought this thread might get moved to developers 

@jondecker

I have finally got to the bottom of the events handling code so I am now happy that the code should function as expected.  It looks like the device_status information is held locally within the CM11A code and hence not passed back to decrouter for the purpose of updating floorplans (this is the bit I was struggling to understand).  DCERouter is only informed of external events if they refer to a security device                                                                                                                                                               such as a motion sensor.

I will not be around for a couple of days, but if you could investigate the possibility of updating floorplan items I believe that would complete the CM11A module, if we are lucky it may only require a few lines of code.

PS the error you experienced in debugging was caused as you were trying to display an item which does not exist within the container !

Feel free to update the trac ticket with the latest code as Dan is hopefully going to test our work shortly

Best Wishes

NOS

[ddamron]

cool, I can chime in here..
What you need to do is simply update the state of the device.
ie if you receive a command via x10 to turn B3 on.. Figure out which device B3 is,
and send it a cmd192...

now, sending STATE is a bit trickier.
To send STATE information, ie B3 50%..
where B3 is device 88
send a command TO 88 FROM 88 cmd 184(SetLevel) yada yada yada
and When you Receive Command for Child, if the FROM == TO, IGNORE.

HTH,

Dan

[jondecker76]

Nice tips Dan - I will be working on this over the next couple of days. Should have this all wrapped up very soon!

[ddamron]

Heh, not a problem, I'll help where I can..

I banged my head over that damn state problem for WEEKS...

now, here's the kicker,

Ideally, to communicate status changes/state changes, the child devices SHOULD send EVENTS..

Notice, I'm sending COMMANDS..

this is because there is no event for STATE.  and to make things even trickier, (at least in gsd) when you send, for example a EVENT ON, the state is changed accordingly.  HOWEVER, because of AVTranslation.cpp (I assume this is only related to GSD devices) when you try to send a COMMAND to change the state back, it gets ignored.

it's hard to explain, and even harder to make a truth table..

In a nutshell, the whole 'state' information needs a revamp.

(This is also associated to SHOWING state information on the Orbiter... as right now, it doesn't)

[jondecker76]

Dan-

I have done a lot of poking around the sources, and it seams to me that there is a state event:
EVENT_State_Changed_CONST defined in pluto_main

Looking at the lighting plugin however, shows:

Code: [Select]

RegisterMsgInterceptor(( MessageInterceptorFn )( &Lighting_Plugin::LightingCommand ), 0, 0, 0, DEVICECATEGORY_Lighting_Device_CONST, MESSAGETYPE_COMMAND, 0 );
    RegisterMsgInterceptor(( MessageInterceptorFn )( &Lighting_Plugin::LightingFollowMe ), 0, 0, 0, 0, MESSAGETYPE_EVENT, EVENT_Follow_Me_Lighting_CONST );
    RegisterMsgInterceptor(( MessageInterceptorFn )( &Lighting_Plugin::DeviceOnOff ), 0, 0, 0, 0, MESSAGETYPE_EVENT, EVENT_Device_OnOff_CONST );
    RegisterMsgInterceptor(( MessageInterceptorFn )( &Lighting_Plugin::GetVideoFrame ), 0, 0, 0, 0, MESSAGETYPE_COMMAND, COMMAND_Get_Video_Frame_CONST );
So the EVENT_State_Changed_CONST isn't even supported..  It would be easy to add it to the lighting plugin though..


Anyways, got some good things done so far today...  I finally have floorplan objects updating to show the state of lights when an external xx10 remote is used to turn them on and off..

[nosilla99]

Hi guys,

Well done, it's great news about the status update events

Keep up the good work

NOS

[caiman]

as I posted the initial mantis for the 0x5A lock with pluto team, I feel ashamed that I could not contribute more so far (except for the ugly heyu workaround). If that helps, I would be more than happy to do some testing of the latest developments. Where can I get a snapshot for 0710b4 ? Is it in SVN or is there a precompiled version around  ?

thanks,
Sam

[nite_man]

I built CM11A from the sources. But It works on strange manner. I don't see any messages in its log except those which are stored there during device initialization.  The lighting works but with a big delay - about 20 - 30 seconds after sending a command.

It'd be really good if somebody from developers share CM11A for i386 and AMD64 similar manner it's done for Media and generic plug-ins on the 0710 Beta4 known issues list.

P. S. Nice to see you again Sam

[jondecker76]

The fix was submitted about a month ago, but it never made it to beta 4 unfortunately. It is however in the svn.linuxmce.com/pluto/trunk. You could download the required files from there:
CM11A/devicepoll.cpp
CM11A/devicepoll.h
CM11A/cm11aconsts.h
Serial/SerialPort.cpp
Serial/SerialPort.h
Lighting_Plugin/Lighting_Plugin.cpp
Lighting_Plugin/Lighting_Plugin.h
pluto_main/Define_EventParameter.h

If you are running 64-bit, i will send you the binaries if you want them.

The fix is 100% stable, and extremely fast (fast for x10 anyways) - everything happens for me in well under a second. Also, I am using this in a house with around 100 active x10 modules (all light fixtures and outlets in the house are X10, as well as many sensors, plug-in modules, and inline modules.