Multiple Actions in Domotiga

[Andy_Burn]

Hi Ron,
I've been trying to switch on/off multiple lights when an event occurs, and I seem to have hit a problem.
If I set up three actions eg Kitchen light off, Hall light off, Dining Light off... I can only ever get two of them to work. The switches are X10, and I have a phase capacitor installed in the distribution box.
If add pauses(0.25s-3s), multiple 'off' commands in different orders, 'dont run this command again within 10seconds' etc, I still have no luck. It seems only the first two or three actions are recognised?

Heres the kicker. If I sit in Control and click one button after the other, it all works. Lol! I spent about a day trying to get this to work! Ha ha ha! It keeps me out of the bar
Any ideas?
Many Thanks,
Andy

[RDNZL]

Which interface are you using to switch the lights?
I will look into this if I have the same hardware to test with.

[Andy_Burn]

I use a TI103 using the Xanura CTX35 interface and XPS3-IW switches

Andy

[RDNZL]

I have a CTX35 to test with, have to search for some of my X10 modules.

But what do you see in debug log window after enabling, Main->Device debug, Main->Event debug and CTX35 debug when this event runs?

Maybe mail it to me directly, as it will probably be a lot of data...

[Andy_Burn]

I had another go at this today.
I enabled logs, but nothing shows. I can send them if you'd like.
The problem occurs when I send multiple requests quickly.
e.g. i have an intruder 'horn' which you send the 'on/off' command four or five times to turn on, the same for off.
If I then randomly turn on fans lights etc, every second or less, DomotiGa aborts after a short while, without warning. My script restarts it a minute later.
It would seem like theres some kind of buffer overload? Either in the program, or in the way updates are performed in memory/database.
I have good signal to all of my devices since I put the TI-103 in the electric distribution box. i.e. no interference
I guess, I should stop going fast

Andy

[RDNZL]

Pls mail logs to address in README file.

[vdoucet]

I have the same with PLCBUS: at a certain time, it should trigger two actions (switch B02 and B06 on for instance) and only does one out of two (the first one in order of apperance in the event window). When looking at the log, I get :

Code: Select all

2011/02/05 21:49:00 [PLCBUS] > 02 05 FA 15 23 00 00 03
2011/02/05 21:49:00 [PLCBUS] > 02 05 FA 15 23 00 00 03
2011/02/05 21:49:00 [PLCBUS] > 02 05 FA 11 23 00 00 03
2011/02/05 21:49:00 [PLCBUS] > 02 05 FA 11 23 00 00 03
2011/02/05 21:49:00 [PLCBUS] < 02 06 FA 15 23 00 00 1C AA 
2011/02/05 21:49:00 [PLCBUS] < 02 06 FA 15 23 00 00 20 A6 Addr: B06 Cmd: OFF Data1: 00 Data2: 00 ON/OFF

Physically, it only triggers B06.
B02 remains in the previous state.

[TimScottz8]

I have also be playing with plcBus and have a similar problem with more than 2 actions in one event. I wondered if it was a timing problem so I put some pause action in between the actual plcbus actions, but this made no difference. I therefore decided to investigate the code so put some breakpoints in to try and see if there was a logic fault somewhere. Bizarrely with the breakpoints in the event worked with no problems. All 3 actions performed as they should which ruined any chance I had of finding the bug. I'll look a this some more, but I am having to learn Gambas at the same time (I always used Delphi/Kylix in the past).
I really want to use Domotiga as it is the last piece in the puzzle to go fully Linux in my household, but this bug is a bit of a show-stopper at the moment. I use PowerHome2 currently but it does not support plcBus other than through the X10 translator unit.

Tim Scott

[TimScottz8]

I've had time to play with this problem some more. Following my hunch that it is a timing problem I added a delay into the code

Code: Select all

PUBLIC SUB WriteCommand(bBuffer AS Byte[], OPTIONAL sKey AS String)

  DIM bByte AS Byte
  DIM iCnt, iLoop AS Integer

  ' bControllerBusy = TRUE
  ' tPLCBUSBusy.Start

  IF NOT bPLCBUSDebug THEN
    bBuffer.Write(hPLCBUS, 0, bBuffer.Length)
    ' --- wait 12.5mS ---
    SLEEP 0.0125
    bBuffer.Write(hPLCBUS, 0, bBuffer.Length)
  ELSE
    '--- send all packets strings twice ---
    REPEAT
      iCnt = 0
      Main.WriteDebugLog("[PLCBUS] >", TRUE)
      FOR EACH bByte IN bBuffer
        IF iCnt >= bBuffer.Length THEN BREAK
        TRY WRITE #hPLCBUS, CByte(bByte)
        IF ERROR THEN SLEEP 0.01
        Main.WriteRFXDebugLog(" " & Hex(bByte, 2), TRUE)
        INC iCnt
      NEXT
      Main.WriteRFXDebugLog("\n", TRUE)
      INC iLoop
      '--- wait 12.5mS ---
      ' SLEEP 0.0125
    UNTIL iLoop = 1
  END IF
  cQueue.Remove(sKey)
  SLEEP 1
END

SLEEP 1 near the end of this code snippet representing the delay. Having entered this delay, which occurs after each action, I was able to run an event with three actions with no errors. Obviously this is not the solution but may help point others in the right direction.

Tim Scott

[TimScottz8]

I have played a little more with the delay timing. For good measure I now have 4 actions turning on PLCBus devices, both dimmable lights and appliances. I found that with the SLEEP value set at 0.5 then the switching of four devices was very reliable, but with 0.4 it was only partially reliable, i.e different combinations of lights came on, not necessarily in the order on the event action list. In other words action 3 might be missed out but action 4 completed with 0.4 set. This seems a very long delay that is required, I expected something of the order of o.02 seconds, not 0.5 seconds. I have not looked far enough into the code to see what error checking is used but I would have thought that maybe the way to go would be to send the commands, poll each device to see if it had switched and if not send the command again with a maximum number of attempts prior to exiting and posting an error message.

Tim

[Digit]

PLCBUS devices send an ACK (if requested, IIRC), so I don't think there's a need for polling. Just sit and wait for the ACK; if it doesn't show up within a certain timeout, you know something's wrong.

[TimScottz8]

I thought about this but came up with a small problem. It is possible to address old X10 units using PLCBus interface and a translation unit. Waiting for old X10 units to ACK won't work. Not an insurmountable problem but one that needs considering

[Digit]

That's a good one
A PLCBUS driver should be able to rely on the fact that all the devices it controls, support all the PLCBUS features they should support.
If not: bad luck, wrong choice. Instead use a real X10 driver/interface for your X10 devices, I'd say.
But that's just my opinion...

BTW, does polling those X10 devices work (by using PLCBUS interface & translation unit)?
If not (and that's what I assume), this 'problem' cannot be solved?

[RDNZL]

I have changed the PLCBUS code, now it sends one command from the queue, waits with timer, and sends next one, until queue empty.
Timer delay is different for 1 and 3 phase installation.
Now polling more than 1 housecode also works, it never did, probably because of the busy controller.
Please test it by copying CPLCBUS.class from svn trunk over yours, and recompile the DomotiGa project.

[RDNZL]

I just uploaded version 0.1.198 wich contains PLCBUS delays for the different commands, device status poll fixes, and scene programming functions in the commander.
Please test and report!