Custom protocol added

Theengs OpenMQTTGateway Radio frequencies gateways 315mhz, 433mhz, 868mhz
1

Hi there this is my first here,

So about three years ago i created my RF openMQTTGateway to control my 433 RF fans.

First i started with pilight and raw protocols but it was quite tricky to follow and keep track of the enormous strings read by the receiver. I finally found rc-switch and openMQTTGw, i used back in the time the protocolanalyzer demo from here https://github.com/Martin-Laclaustra/rc-switch/tree/protocollessreceiver/examples/ProtocolAnalyzeDemo (i think) to find the custom protocol. Once added it worked very accurate and the database string of codes for speed where much shorter.

Now i need to change some hardcoded values (the broker ip) due to some changes in the network. I have an old openmqttgateway git folder with the custom protocol added there, and looking now at the current forked RC-switch list of protocols under src/RCSwitch.cpp i can see the list is much larger now, also the protocol string length is kind of different now.

Question is will this custom RF protocol from back in time work in current openmqttgateway.

{ 335, { 35,  2 }, {  1,  2 }, {  2,  1 }, true } // Protocol 8 RF FAN 433

The current rf protocols look like this now

{ 220,  0, { 0, 0 }, 1, {   1, 46 }, { 1,  6 }, { 1, 1 }, false,  2 }, // 29 (NEXA)

Or i have to rerun another protocol analyser?

I can see now that web portal can be enabled to change some of those configs.

2

Hi,

I don’t think so.

I suggest that you take some examples of protocol with the same structure as yours in the original RCSwitch repo or in the history of the fork and apply the same logic that was applied on the latest fork revision.
Example:
{ 320, { 36, 1 }, { 1, 2 }, { 2, 1 }, true }

is now

{ 320, 0, { 0, 0 }, 1, { 36, 1 }, { 1, 2 }, { 2, 1 }, true, 0 }

The web portal enable you to change the wifi, mqtt credentials and also the gateway name/base topic.

3

Thanks i understand now. i’ll dump the old fw for backup first, and rebuild using that format.

Yes i understand, my mistake on the words. The protocols get hard coded in the fw, the network settings and mqtt can be changed now

4

It’s also possible that the new version is compatible out of the box with your signals, especialy with the example I gave you which is very close.
The only difference is the pulselength; 320/335
And as RCSwitch apply a receive tolerance I think it will be caugth.

5

It could be but i think i would have to record all signals again right?. I have 4 fans each of them with 7 speed, plus light toggle, that’s 32 diff signals.

I’ll give it a test and report back

6

It’s different signals but this should not change the protocol and the values that you are using.
We will see.

7

ok. protocol 8 works default with the fan remotes. Problem is now payloads are json, so a little bit more work to do.

Took me a while to set up, it wouldn’t connect, the key was to erase the flash.

Now apparently there is an issue using static ips? is that correct? only dhcp works for the moment?

8

You can revert back to simple one by activating simplepublishing
But I would prefer to make the extra effort to go to json.

I don’t think so, did you tested it?

9

Yes it doesn’t work. Saw a similar thread in github and didn’t pursue anything else. I am ok for the moment with that but general rule in my esp devices all have static ip.

I used version 0.9.4