• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
action: switch
#31
I now moved my RPi with the transmitter to a location just over 1 meter away from the kaku AWMR-300 switch. This gives no improvement whatsoever: The switch doesn't respond most of the times, when the pilight device is switched. It responds perfectly well to the remote.

If I move the remote so far away that the switch doesn't respond to a short keypress anymore, it still responds if I keep the key of the remote pressed for a few seconds (so it is repeating).

My conclusions:
  1. The cause of the switch not responding, is definitely not a matter of the signal being too weak.
  2. Having the possibility to increase the send repeats will improve the response of the switch (like it did before).
So please give me back the possibility to increase the transmit repeats, either globally or on a per device basis.

For now I am afraid that I have no other possibility then to stop using this version and revert to the one just before the send repeats were changed. That however will mean that it will become difficult for me to contribute, because I use pilight in daily practice and I don't have a separate development system available. Crying

Edit 1:
I restored version 6.0, commit d9f408e. That is the one just before the commit titled "Greatly simplified 433.92Mhz stream parsing" (commit 748e5e7). With commit d9f408e the switch responds to all "on" commands again, but still misses on average 2 out of 3 "off" commands. Quickly switching 2 or 3 times between "on" and "off" almost always makes the switch finally go to "off".

So commit 748e5e7 made the switch respond even worse, but it already started to get bad with the commit titled "Make send-repeats protocol unique instead of global" (commit 3780348).

So next step is getting back to a version before commit 3780348, where my switch still nicely responded to all commands. Probably I'll have to stay on that version then, until there is a solution.

Edit 2:

In commit 748e5e7 I changed in arctech_switch.c:

Code:
#define NORMAL_REPEATS  10 to
#define NORMAL_REPEATS  20

Now my switch is working like a charm again (from the gui at least). Smile
With this modification there is no need going back to an earlier commit and I will try if the same trick works with the latest commit too.

What about adding an optional "send-repeats" setting to the protocol that overrides NORMAL_REPEATS?

Edit 3:

Tried the modification from edit 2 to version 6.0, commit 5ee706a, without any success. The switch still misses most of the swich commands. So I think that "Greatly simplified 433.92Mhz stream parsing" introduced another problem that is possibly not related to the send repeats issue.

Edit 4:

I did what I should have done in the first place. I compared the raw codes from pilight (commit 5ee706a) with those from the remote and I see a significant difference:

Code:
pilight: short pulse 300, long pulse 1500, so multiplier=5
remote: short pulse 297, long pulse 1188, so multiplier=4
I guess that can explain why my switch doesn't respond.
 
Reply
#32
Awaiting your pull request Smile
 
Reply
#33
I tested with a multiplier of 4 with immediate success. I could even set the repeats in the protocol back to 10.Smile

So I will be happy to do a pull request for the arctech_switch and I think I should do that for the arctech_screen too (controlled by the same remote as the switch).

But just to be sure, kaku is just one of the brands of switches controlled by the arctech_switch protocol. I only have the kaku so I cannot check if other brands also need the multiplier of 4 instead of 5.

The raw code example in the arctech_switch wiki (nightly) differs from the codes sent by my remote. The wiki shows three different pulses, globally 220, 270 and 1355. My remote is sending only two different pulses, globally 300 and 1200.

This could mean that not all brands controlled by the arctech_switch protocol will like changing the multiplier.

Please advise.
 
Reply
#34
I think all kaku variants will be the same.
 
Reply
#35
@curlymo,

You asked for a pull request and I did one, although it is just a small fix.
Shall I merge it myself?

The arctech_contact protocol didn't work either, but just changing the multiplier here didn't solve it. I found some errors in lines 37 and 38 where the MIN and MAX values values were swapped. The same goes for lines 100 and 101. After changing those, my contact worked only half. pilight-receive showed the "closed" condition, but didn't show the "opened" condition.
When I looked at the pilight-debug output, I saw that the arctech_contact is sending with different raw lenghts for "opened" and "closed" (148 vs. 132). After changing the raw length check in the validate function to 148, the behaviour swapped and only the "opened" condition was shown.
Finally I changed the validation check to

Code:
if(arctech_contact->rawlen == MIN_RAW_LENGTH || arctech_contact->rawlen == MAX_RAW_LENGTH) {
so it now accepts both raw lengths.

Question: this solution works, but is this a correct way to solve this issue?
 
Reply
#36
Yes
 
Reply
#37
The multiplier also needs to be changed for arctech_dimmer, confirmed it fixes it.
 
Reply
#38
Done
 
Reply
#39
Does this also fix your reception problem?
 
Reply
#40
@curlymo,

Both the kaku switch and the kaku contact are working fine now with these fixes. No reception problems at all.

I don't own a kaku dimmer, so hopefully kaku dimmer users can confirm that that one is OK now too.
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  _VARSTORE_ set action fourty2 1 1,036 05-19-2019, 09:07 PM
Last Post: curlymo
  skipping overridden action switch do1eh 2 690 01-19-2019, 05:25 PM
Last Post: do1eh
  http action Niek 21 4,684 08-12-2018, 11:44 AM
Last Post: rorie
  Can't switch Relay device by rules: Error switch.lua:77 wobbi 6 1,094 07-31-2018, 06:25 AM
Last Post: curlymo
  Send on command when switch is already "on" joshovki 1 633 01-28-2018, 11:27 PM
Last Post: curlymo
  action: Pushbullet bazb 24 12,152 01-04-2018, 08:38 PM
Last Post: curlymo
  action: pushover Niek 36 18,494 12-03-2017, 11:13 AM
Last Post: Alex
  Problem with a Rule for a One Button Switch martin-dj 1 1,347 03-06-2017, 12:01 PM
Last Post: pilino1234
  duration switch protocol creamers 6 2,557 01-10-2017, 10:04 PM
Last Post: wo_rasp
  action: file Niek 14 4,373 06-23-2016, 04:02 PM
Last Post: Niek

Forum Jump:


Browsing: 1 Guest(s)