RFXcom (lan) with DomotiGa (for KAKU)

[RDNZL]

About issue 1, I will look into this, have to use the combolist index instead of the contents.

Issue 2...
I have changed the toggle code so it works on older gambas revisions.
I also updated the binaries, maybe you didn't recompile your code.
It should work now.

About receiving KAKU transmitter signals...
Do you have a 433Mhz receiver module installed?
Don't you see any packets coming in, even when debug is enabled?
Do you see data when you connect with windows rfxreceiver.exe to the domotiga rfxreceiver relay port?

[yjb]

Hi,

Not sure what KAKU remote you've got, I've got a APA3 unit. When pressing the switches you will see the following in the debug log:
2011/03/16 11:36:57 2210899DD090 HE Device=0422677 Unit=1 ON bits=34
2011/03/16 11:37:03 2210899DD180 HE Device=0422677 Unit=2 ON bits=34
2011/03/16 11:37:05 2210899DC1E0 HE Device=0422677 Unit=2 OFF bits=34
2011/03/16 11:37:06 2210899DC2E0 HE Device=0422677 Unit=3 OFF bits=34
2011/03/16 11:37:07 2210899DD2E0 HE Device=0422677 Unit=3 ON bits=34

Based upon that I've defined 3 switches (picture shows unit 1):

kaku_remote.jpg (38.34 KiB) Viewed 10169 times

As you can see you will need to expand the HE Device number with the Unit number.

Right now I'm using a lamp icon, might be an idea to add 2 icons (switch on / switch off) to the image repository.

Ysbrand

[insomniux]

OK, the toggle option does work!. Great
With respect to the remote, I find this in the logs (yes, receiver is installed, and I do receive a signal, and the signal is shown in the logs):

Code: Select all

2011/03/16 19:20:31 20708F48B7 B7-On bits=32
2011/03/16 19:20:31 20708F48B7 B7-On bits=32
2011/03/16 19:20:31 20708F48B7 B7-On bits=32
2011/03/16 19:20:32 20708F48B7 B7-On bits=32
2011/03/16 19:20:32 20708F48B7 B7-On bits=32
2011/03/16 19:20:32 20708F48B7 B7-On bits=32
2011/03/16 19:20:32 20708F48B7 B7-On bits=32
2011/03/16 19:20:32 20708F48B7 B7-On bits=32
2011/03/16 19:20:32 20708F48B7 B7-On bits=32

What I did is:
1. define the KAKU transmitter as AWST-8802
2. copy the ID from the log into the ID field
3. define a switch with codewheel setting B7
4. create a trigger: If the transmitter = B7-On
5. create two action: (1) delay 10 secs; (2) switch device B7 Off

This does not seem to work. Do I miss an important clue here?
Thanks again

[RDNZL]

What do you mean with:

2. copy the ID from the log into the ID field
3. define a switch with codewheel setting B7

Is this the packet from the switch or from an appliance/lamp you want to switch?
You cannot switch a switch with rfxmitter, a switch only sends, I cannot follow your story.

You only talk about B7, you cannot control a AWST-8802 with rfxmitter, only read the packets it sends with rfxreceiver and switch something else with it, what is that something else?

[insomniux]

Of course it is clear that you cannot control a KAKU transmitter, only read its signal (On or Off). DomotiGa actually detects the signal but it seems to be impossible to activate a DomotiGa trigger by catching Value1="B7-On" / Value1="B7-Off" (or just "0n" or "Off"). What I want to achieve is that when a switch (eg B7) sends On or Off, that that signal is caught and I can use that to control other devices (eg B8-B10) with different delays or so.

2. copy the ID from the log into the ID field (I mean DevUnit)
3. define a switch (ARC - device) with codewheel setting B7 (a PAR 1000 device)

[RDNZL]

Please activate events and devices debug (Setup->Main->) and send me the debug log part (to email address from README file) or post it here if its not to big...

The fact that you don't see anything like this, should mean that the B7 device is configured correctly.

2011/03/17 09:45:53 20708F48B72011/03/17 09:45:53 [Devices] Device 'X10' with address 'B07' and interface '' not found!
B7-On bits=32

[RDNZL]

2011/03/16 19:20:31 20708F48B7 B7-On bits=32

After looking better at your situation, are you sure this comes from your AWST-8802 ?

You should get a HE DeviceUnit address, not a X10 address.

[insomniux]

You're right, in fact the signal comes from an (old) TMT 2100 remote control of KAKU. Furthermore my transmitters are the wallmount wst8700. All devices in my house are the older model with 2 switch-wheels. The only transmitter in the standard list of Domotiga is the AWST8802, couldn't find older transmitters from KAKU. It appears that this transmitter uses the HE protocol... Should I actually define another module, using the AC (or ARC?) protocol with DevUnit format A1?

[RDNZL]

Even if you don't have any device configured for it in DomotiGa, if the RFXReceiver picks up signals you should see them in your normal log, they look like "cannot find device with address xxx and interface "RFXCom Receiver"

And if you enable RFXComRX debug, you see even more detailed info, including the complete RF packets that came in.

If you don't see any of these, either the transmitter is not sending signals (dead battery, no power), doesn't work or is out of range of RFXCom receiver.
If you are sure that the module is sending data and your interface is working, please start rfxreceiver.exe under windows attack to rfxcom interface and post me the data it finds, but I have advised that above already.
What is the firmware version of your receiver module?
wst8700 unsupported?

As far as device modules concerned, only the protocol matters (you the protocol in the debug log when a packet comes in) and choosing the right interface.
It can have any name you want.

[insomniux]

OK, clear.

To see which protocol is required you can watch the log and select the Device which is mentioned in e.g.

Code: Select all

2011/03/18 21:31:30 20708F609F2011/03/18 21:31:30 [Devices]  ==> Device 'X10' <== with address 'B05' and interface '' not found!

If the device is not in the dropdown list, select any device of the same 'type' (in my case I could use KAKU Chime) and GO....

AND the nice thing is ..... that it actually works although my system is ARC and NOT X10 .... it's a miracle but i don't understand how

Thanks for your support !

[RDNZL]

Once there was an RFXreceiver which picked up all kinds of data out of the sky, and dumped it as a string on it's interface.
Most of the data was converted to an X10 format. (except Oregon for example)
Then a RFXtransmitter came which followed the same path, and supported ARC, AC, and HE protocols

Then there was the urge to add another protocol to the transmitter, but there was no memory space left to put the extra code in, so the X10 conversion was removed to make room and the raw protocols where used instead, then the RFXmitter was born.

So there you have the reason why some of them don't match up anymore in DomotiGa, I should create a small conversion table, so it's clear which device uses which protocol when received, and transmitter perhaps...

[insomniux]

Ahh... I understand, we're part of a nice fairy tale Hope there once will come a good fairy which will make all your (and our....) dreams come true!!!

OK, another question, which may be KAKU-related (or ARC).

simplified: I have 2 KAKU lamp switches B1 and B16. I made events that turn them of 600 secs after turning them on.

When I turn them ON directly after eachother (some seconds in between), DomotiGa forgets the first trigger and turns OFF the last one only. Is this a bug, a feature or just a non-addressed issue ....

BTW I noticed I cannot define an ARC device B1-receiver and B1-transmitter because it wants a unique address for each ARC device (I guess). This means that I can not distinguish between signals from the Transmitter (my KAKU wallswitch) and signals from DomotiGa which change the device status. Wouldn't it be useful to be able to define eg a B1 XRFreceiver and B1 XRFtransmitter? ARC now recognizes the XFRCom Transmitter only?

Cheers

[insomniux]

OK guys, after some experimenting I succeeded in what I wanted to achieve. And want to share it with other newbies...

Since the timer (delay) function is not working as I expected (previously started delay-actions are ignored) and it is somewhat unreliable, I searched for another solution. Why is the delay-timer unreliable: if your DomotiGa server is interrupted (power failure, reboot, restart of DomotiGaServer, etc) the action is lost into space and will not do what you expect. Not usefull if you want to switch off your central heating or lights during the night or so.

There are some other things to realize:
You cannot used the Variable Second as a trigger, Minute does work. However you can use the variable Second in conditions. This means that the exact time to trigger the event depends on 'where' in the minute period your event is triggered. If it is triggered at 8:00:59, the first 'minute trigger' takes place 1 second later. If it is triggered at 8:01:01, it will take at least 1 minute. Not a big issue, but good to realize.

How did I configure my timers (e.g. to switch off a light (approx) 5 minutes after being switched on):

1. Define a device (in my case a KAKU-ARC receiver). It got ID number 40
2. Create an Event and Enable it
3. In the Event window: create a trigger (I called it: Trigger each minute (24x7) )
3a. In the Variable tab: set variable Minute <> 60 (variable Second will NOT be evaluated and will not work!)
3b. Save the trigger
4. In the Event window: create a condition (I called it: Light X off in 5 minutes)
4a. Enter the following code

Code: Select all

Dev_40_Value = "On"
AND
DateDiff(Dev_40_LastSeen, Now(), 1)>300

Code: Select all

EXPLANATION
Where  40 is the ID of the device (1st column in the device window)
the last parameter (1) in the function DateDiff means evaluate 'Seconds. In this case 300
I assume that 2=minute, 3=hour, 4=day (how does this proceed? week?month?year?)
I could not find out if it is possible to make annotations in the condition field (to explain what the code means)

4b. Save the Condition
5. In the Event window create an Action (called it: Light X off):
5a. In the Device tab, select the device name and set Value1 to Off
5b. Save the Action
6. Save the Event

This works even after server interruptions since it completely relies on entries in the database records, AND, more important, if you have an interruption in any other system (Tranceiver, RFXCom, etc) it still will execute the trigger as long as the status in the database meets the condition defined at point 4.

Hope this is off any help to others.
Cheers!