• 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
pilight Nano USB interface
Did you try sending this unit/id combination pilight-receive recognizes?
No I didn't think that was necessary given the unit/id combination received is 0,0 and the same for both working transmits (11,0 & 7,0)

You can also see that it looks like the nano is not respecting the longer pulse widths in the protocol message on a HIGH pull, only on LOW (from viewing the capture).

I'll try a raspberry pi tonight.
I will look into it myself. This seems more of a protocol issue than firmware one. Maybe @wo_rasp can take a look?
Yes - this is what it's supposed to look like

[Image: klik%20aan%20klik%20uit%20timing%20diagram.png]

Appreciate you looking into it thanks!
The problem is that what you are sending with RCSwitch is not KaKu Old. Compare the arctech_switch_old wiki codes with yours:

Arctech Switch Old
295 1180 295 1180
295 1180 1180 295

RC Switch
380 1140 380 380
380 1140 380 1140
I find it hard to believe that it is RemoteSwitch which is wrong given that I instantiate a KakuTransmitter object, give it the correct codes and it works...

Have you noticed from the signal capture that the nano never sends a long high pulse it only has long low pulses, therefore it can't represent a binary 1, acvording to the pulse lengths you just quoted.

Just look at the images and the last I posted.

Can't look at the Pi tonight as my daughter is unwell.

I'll try Kaku new tonight on the nano, but from all my searching on line these devices use the byebye standby protocol (ie kaku old). I appreciate the help
As a first overview i think the pulsed high signals are a bug.
A bug in what, pilight or RCSwitch?
I assume it is in pilight.
I am currently doing some more background checking on ITT-1500 remote (arctech) and RCS-1000SN (Brennenstuhl).
The remotes cover larger than expected distances, but the pilight generated pulses do not.

Just tested the quigg-gt7000 with the Arduino nano: receive won't work, transmitting neither, but here i still have to check my setup.
Brennenstuhl RCS 1000SN: recognized as elro_400_switch, elro_800_switch, elro_800_contact, ev1527
tfa is recognized and okaz (tfa 30.3200 device)
ITT-1500 recognized as: arctech_screen, arctech_switch, arctech_contact
Appreciate it, thanks

Possibly Related Threads...
Thread Author Replies Views Last Post
  how to compile pilight with custom protocol code? am i missing something? stanwebber 2 90 07-05-2021, 03:49 AM
Last Post: stanwebber
  hardware info lost after pilight restart Rschnauzer 3 259 03-17-2021, 11:44 AM
Last Post: Rschnauzer
Question pilight stopped working sl4m01 3 957 11-26-2020, 09:17 PM
Last Post: PPacman
  pilight-raw changes output format from 7 to 8 Rschnauzer 1 641 11-26-2020, 01:52 PM
Last Post: curlymo
Question pilight nightly webgui offline after some hours fleisch 4 694 10-26-2020, 05:19 PM
Last Post: fleisch
  pilight bugs Ascenion 1 664 03-23-2020, 06:29 PM
Last Post: curlymo
  [Solved] pilight service crashing on first webserver access after reboot VrahoK 20 4,521 12-21-2019, 09:46 AM
Last Post: curlymo
  pilight-control modify values coolinx 16 3,631 11-13-2019, 08:02 PM
Last Post: curlymo
  Bug: double free or corruption in pilight-send blackzombie 12 3,105 10-07-2019, 08:15 PM
Last Post: blackzombie
  [Fixed] High CPU usage when pilight usb nano disconnects DieterK 1 986 08-13-2019, 05:43 PM
Last Post: curlymo

Forum Jump:

Browsing: 2 Guest(s)