RF2 (KaKu) problems on 0.96

Bert · May 14, 2021, 12:17pm

Hi all,

My first post on the forum because I’m at a loss. I can’t get the RF2 to work, problem sounds much like:
https://kaku-acd-1000-and-flamingo-sf-501p-switch-dont-respond-on-omg-rf2-sent-signal

I’ve tested on master branch and developement (both cloned on May 13th)

In the serial monitor I can see my button press:

N: Subject: /RF2toMQTT
N: Received json : {“unit”:9,“groupBit”:0,“period”:262,“address”:28861626,“switchType”:1}
T: jsonPublishing
T: simplePublishing
T: Creating RF2 buffer
T: Rcv. RF2
N: Subject: /RF2toMQTT
N: Received json : {“unit”:9,“groupBit”:0,“period”:262,“address”:28861626,“switchType”:0}

But this doesn’t work:

T: Hey I got a callback home/OpenMQTTGateway/commands/MQTTtoRF2
N: Received json : {“unit”:9,“groupBit”:0,“period”:262,“address”:28861626,“switchType”:0}

Finally I’ve tested the Dimmer sketch example from the NewRemoteSwitch library, that worked!

NewRemoteTransmitter transmitter(28861626, 4, 260, 3);
transmitter.sendDim(9, );

The build flags:

build_flags =
${com-arduino.build_flags}
‘-DZgatewayRF=“RF”’
‘-DZgatewayRF2=“RF2”’
‘-DRF_RECEIVER_GPIO=1’ #D3 on UNO
‘-DRF_EMITTER_GPIO=4’ #D4 on UNO
‘-DZsensorDHT=“DHT”’
‘-DDHT_RECEIVER_GPIO=8’ #D8 on UNO
‘-DZsensorDS1820=“DS1820”’
‘-DDS1820_OWBUS_GPIO=2’ #D2 on UNO
‘-DZgatewayIR=“IR”’
‘-DIR_RECEIVER_GPIO=9’ #D9 on UNO
‘-DZmqttDiscovery=“HADiscovery”’
;‘-DsimplePublishing=true’
‘-DsimpleReceiving=true’
‘-DjsonPublishing=true’
‘-DjsonReceiving=true’
‘-DLED_RECEIVE=7’ # red D7 on UNO
‘-DLED_SEND=6’ #orange D6 on UNO
‘-DLED_INFO=5’ #green D5 on UNO
‘-DGateway_Name=“OpenMQTTGateway”’
‘-DNTP_SERVER=“pool.ntp.org”’
‘-DLOG_LEVEL=LOG_LEVEL_TRACE’

I’ve tested both simpleReceiving as well as json.
Checked, re-checked and triple checked my connections and power. (and then checked again)

Anybody got some ideas where to look?

Regards,
Bert

NorthernMan54 · May 14, 2021, 4:21pm

Please keep in mind that the current development branch has a new feature, receiver switching Active Receiver Switching by NorthernMan54 · Pull Request #936 · 1technophile/OpenMQTTGateway · GitHub ) which may make things behave differently. So you may want to focus on one of the two.

I was reading your comment but couldn’t figure out what your issue is, can you elaborate ?

ie receive doesn’t work or send doesn’t work

Bert · May 14, 2021, 4:45pm

Hi @NorthernMan54

I have read the active pull request. I was on the master branch but then, cause I couldn’t get it to work, switch to Dev in the hope it would resolve my issue.

Problem is sending doesn’t work (or receiving by the Kaku depending on your point of view )

With the mentioned config I am able to send and receive normal RF adapters. When I switch to just RF2 in the config I can see the received code from my Kaku remote.

As mentioned when I use an example sketch from the NewRemoteSwitch lib, everything works fine when using the same port for sending

NorthernMan54 · May 15, 2021, 2:10am

Looking at the RF2 code in detail, to match your example of using the NewRemoteSwitch you need to trigger this function on line 216 with a value of 9 in valueUnit

github.com

1technophile/OpenMQTTGateway/blob/f69906861dae2d44865ffef9536714257df99f19/main/ZgatewayRF2.ino#L216


if (valueUNIT == -1)
  valueUNIT = 0;
if (valuePERIOD == 0)
  valuePERIOD = 272;
NewRemoteReceiver::disable();
Log.trace(F("Creating transmitter" CR));
NewRemoteTransmitter transmitter(valueCODE, RF_EMITTER_GPIO, valuePERIOD);
Log.trace(F("Sending data" CR));
if (valueGROUP) {
  if (isDimCommand) {
    transmitter.sendGroupDim(valueDIM);
  } else {
    transmitter.sendGroup(boolSWITCHTYPE);
  }
} else {
  if (isDimCommand) {
    transmitter.sendDim(valueUNIT, valueDIM);
  } else {
    transmitter.sendUnit(valueUNIT, boolSWITCHTYPE);
  }
}

Which if I read the code correctly ( may need some testing or further review ), needs a switchType of 2 versus a zero in your example send command.

Bert · May 15, 2021, 11:33am

I’ve looking at that part of the code too. My group(Bit) is “0”, so valueGROUP would be false So the actual line run is L222 or L224. I’ve added some Log statements to the code and I can confirm that is the case.
As far as I understand switchtype 0 is “off” switchtype 1 is “on” and switchtype 2 is used when you want to send a dim command.

Meanwhile I’ve been testing and I’ve set up another Arduino Mega and, building on the Dimmer sketch, added some PubSub code for MQTT. At first just a transmitter hooked up to it with some jumper cables. That worked!

Then added the receiver all using the same pins but with the address and pins hardcoded. (only dim level is processed from MQTT) Just like OMG I disabled the receiver before sending and enable it afterwards. → Still working

Connected my soldered sensor board. Then it’s not working. So I assume there’s something with my soldering. Then I connected 3 straight cables from my connector to the transmitter. it works again

Oke, some progress… Even when I move my transmitter to the connector it keeps working; as long as I keep it connected through jumper cables.

Then I used this same setup with the OMG, no joy…
So perhaps a multi-part problem; my soldering skills but also something in OMG??

NorthernMan54 · May 15, 2021, 1:25pm

Is it possibly which GPIO you are using ?

I ran into a case with an ESP32 / CC1101 transceiver last month where I went to use gpio2 as an input (GDO0) and inadvertently bricked my device. GPIO2 had been used for output successfully and by a fair number of people ( it was part of the recommended wiring for a cc1101 ). After much research into why I had bricked my device I found that GPIO2 was used as part of the boot process, and holding it low put the device into serial boot loader mode. Cutting the wire to gpio2 unbricked things.

Bert · May 16, 2021, 8:10am

GPIOs are set in the build_flags.

‘-DRF_RECEIVER_GPIO=1’ #pin3 on MEGA (uses interrupt number #1)
‘-DRF_EMITTER_GPIO=4’ #pin4 on MEGA

I know of the issues with ESP32/Nodemcu. I’ve ran into them myself too Stay away from GPIO0 and 2 if you can. I’m using an Arduino Mega 2560 so AFAIK no issues with “forbidden” pins.

You’ve given me an idea though; Could it be that the message is triggering an interrupt while sending?

I think I’ll attach a debugger and compare OMG vs the Dimmer sketch

Bert · May 16, 2021, 8:04pm

Oke, so a little step forward.

ArduinoJson

While debugging I’ve found some anomalies; while OMG was sending to RF2 it suddenly jumped to the ArduinoJson library, specifically to .\.pio\libdeps\megaatmega2560-rf-bdn\ArduinoJson\src\ArduinoJson\Serialization\JsonWriter.hpp This happened somewhere when it was doing a digitalWrite from the wiring.c library and it happened every time.

I then -just to be sure- wanted to import the ArduinoJson lib into my Dimmer_test sketch to see if there was some interoperability issue. However I decided to import the Dimmer sketch in VScode/platformIO to have a good comparison.
I noticed there were some version differences so I updated my platformIO libraries (turns out the version of ArduinoJson is specified in platformio.ini so it didn’t make a difference) But while upgrading in PIO I also updated the “platforms and packages” +p or pio update.
After that debugging was different. It didn’t jump to the ArduinoJson lib anymore but still no joy

Ethernet

Comparing my other libraries I also saw the Ethernet library (I use an Arduino mega 2560 with W5100) had a different version than my Arduino IDE and in the debugger there was some funky stuff happening with this library.
If you look at the registry of libraries in PIO there are 2 Ethernet libraries, both by Paul Stoffregen, but 1 updated for Teensy (which also lists that as it’s only compatible platform) and 1 for all the other platforms and has version 2.0.0 as it’s number.

I’ve modified

github.com

1technophile/OpenMQTTGateway/blob/9ab6e724344a8556f77b5240384006db21b68c86/platformio.ini#L109


      
          dht = DHT sensor library@1.3.0
          unifiedsensor = Adafruit Unified Sensor@1.0.2
          tsl2561 = Adafruit TSL2561@1.0.3
          bme280 = SparkFun BME280@2.0.4
          bmp180 = BMP180#efac46bd8d
          htu21 = SparkFun HTU21D Humidity and Temperature Sensor Breakout@1.1.3
          ahtx0 = Adafruit AHTX0
          ina226 = https://github.com/jarzebski/Arduino-INA226.git#968a684
          a6lib = https://github.com/1technophile/A6lib.git
          wifimanager = https://github.com/tzapu/WiFiManager.git#c3ff582
          ethernet = Ethernet
          esp8266_mdns = esp8266_mdns
          wire = Wire
          fastled = FastLED@3.3.2
          onewire = OneWire
          dallastemperature = DallasTemperature
          m5stickc = M5StickC@0.2.0
          m5stickcp = https://github.com/m5stack/M5StickC-Plus.git#0.0.2
          m5stack = M5Stack@0.3.1
          smartrc-cc1101-driver-lib = SmartRC-CC1101-Driver-Lib@2.5.5
          stl = https://github.com/mike-matera/ArduinoSTL.git#7411816

to read ethernet = arduino-libraries/Ethernet@^2.0.0 Now no more strange behavior in the Ethernet library.

However still no luck sending RF2…

NewRemoteSwitch

Still debugging I also noticed the “repeats” for the transmitter were set to “15” so I changed:

github.com

1technophile/OpenMQTTGateway/blob/9ab6e724344a8556f77b5240384006db21b68c86/main/ZgatewayRF2.ino#L289


      
          int valueDIM = RF2data["dim"] | -1;
          if ((valueCODE != 0) || (valueUNIT != -1) || (valuePERIOD != 0)) {
            Log.trace(F("MQTTtoRF2" CR));
            if (valueCODE == 0)
              valueCODE = 8233378;
            if (valueUNIT == -1)
              valueUNIT = 0;
            if (valuePERIOD == 0)
              valuePERIOD = 272;
            NewRemoteReceiver::disable();
            NewRemoteTransmitter transmitter(valueCODE, RF_EMITTER_GPIO, valuePERIOD);
            Log.trace(F("Sending" CR));
            if (valueGROUP) {
              if (isDimCommand) {
                transmitter.sendGroupDim(valueDIM);
              } else {
                transmitter.sendGroup(boolSWITCHTYPE);
              }
            } else {
              if (isDimCommand) {
                transmitter.sendDim(valueUNIT, valueDIM);

And L213 (simpleReceiving) to read: NewRemoteTransmitter transmitter(valueCODE, RF_EMITTER_GPIO, valuePERIOD, 3);
And → Hey I got a callback Lights are switching on and off again!!!

Now I was getting somewhere so I enabled all other modules which I had disabled for debugging. Now it’s broken again… Turns out I can’t enable DS1820 or IR without breaking RF2

Maybe some timing issues ??

debugging

This part is for anyone who wants to get the debugger working in VSCode and also for myself as a note for future reference.

To get debugging working was a whole other ordeal. I’ve used the jdolinay/avr-debugger library and had to set

debug_port = \.\COM8
debug_tool = avr-stub
build_type = debug

As well as

#include “avr8-stub.h”
…
void setup() {
//Launch serial for debugging purposes
//TODO Remove debugging
debug_init();
Serial3.begin(SERIAL_BAUD);
Log.begin(LOG_LEVEL, &Serial3);
Log.notice(F(CR “************* WELCOME TO OpenMQTTGateway **************” CR));
…
}

And you have to know where attachInterrupt() is called and comment out those statements like in the NewRemoteReceiver.cpp file.