Question: non-stop broadcast from rouge device

[DeadEnded]

Hello!

I am working on my first implementation of the rtl_433 and it has gone rather well. I was able to get help here on getting my configuration up and going (docker image I used was old, so I built my own, yay!).

So now I have ran into a problem I hope someone on here can share some insight on. My receiver appears to be bombarded with broadcasts from a neighbors Acurite 606TX sensor. I can disable the protocol so it doesn't generate a ton of unnecessary messages - but my bigger problem is that I believe my sensors are not being "heard" because of this. I have a significant amount of missed signals even when right next to the antenna. Some get through, so I can only guess that the Acurite sensor is causing the problem.

Here is the log from when I start up (generating JSON for MQTT messages). As you can see there is a constant stream of broadcasts from this rogue sensor - just to clarify - this is not my sensor, but a neighbors somewhere. I don't know who's but if push comes to shove, I might start knocking on doors...

rtl_433 version 18.12-114-gc389edd branch master at 201902231935 inputs file rtl_tcp RTL-SDR, Trying conf file at "rtl_433.conf"..., Trying conf file at "/root/.config/rtl_433/rtl_433.conf"..., Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"..., Trying conf file at "/etc/rtl_433/rtl_433.conf"..., Registered 96 out of 120 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 62-64 67-71 73-100 102-103 108-116 119 ], Found Rafael Micro R820T tuner, Exact sample rate is: 250000.000414 Hz, [R82XX] PLL not locked!, Sample rate set to 250000 S/s., Tuner gain set to Auto., Tuned to 433.920MHz., {"time" : "2019-02-24 18:17:17", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:20", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:21", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:23", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:24", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:26", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:27", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:29", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:30", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:32", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:33", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:35", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:36", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:38", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:39", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:41", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:42", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:44", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:45", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:47", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:48", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:50", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:51", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:53", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:54", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:56", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:57", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:17:59", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:00", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:02", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:03", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:05", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:06", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:08", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:09", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:11", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:12", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:14", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:15", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:17", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:18", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:20", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:21", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:23", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:24", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:26", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:27", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:29", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:30", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:33", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:35", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:39", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:41", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:42", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:44", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:45", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:47", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:48", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700}, {"time" : "2019-02-24 18:18:50", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700},

Besides the fact that this might be illegal (read a little on the 433.92Mhz band being restricted to 2 seconds per hour of broadcasting) - what can I do about this? I expect that my receiver just can't distinguish one sensor from another due to this constant broadcast.

Any/all help and comments are welcome!

Thanks again, DeadEnd

[zuckschwerdt]

Very annoying indeed. You can start by looking at the waterfall in CubicSDR or Gqrx to gain more insight about signal strength, periodicity and frequency. If that doesn't work try -M level to get an idea what rough frequency your sensor is on and where the noise is. If you are lucky you can tune the center frequency away from the noise. E.g. the default of 250k covers a total of 250k "window" of frequency. If your sensor was on 433.90 and the noise on 433.85 then choose 433.87M+125k: -f 433.995M.

In extreme cases you might want to try a "hardware" solution… like they say, if it doesn't work, whack it. If it breaks it needed fixing anyway ;)

[DeadEnded]

Thanks for the information. I did another small capture (only a few seconds). It doesn't look good as far as freq. I cut it down to the high and low from the rogue sensor, one from mine, and a third from another neighbors smoke detector.

It looks like they overlap, although the Acurite might be a little higher... I might be able to shift and narrow to reduce the amount of interference, but there will still be some I expect.

I'll be honest I am just learning about the rssi, snr, etc. From what I have read, the snr and noise readings are not good. If I understand this correctly, being close to 0 on the 0-120 scale means the noise is close to the signal strength - although this could be a result of the Acurite spamming possibly? The rssi being close to zero is actually good, correct? So the signal is strong - there are just to much of them :-) - is that correct?

Thanks again! DeadEnd

{"time" : "2019-02-24 19:20:35", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700, "mod" : "ASK", "freq" : 433.905, "rssi" : -1.792, "snr" : 11.602, "noise" : -13.394}

{"time" : "2019-02-24 19:20:21", "model" : "Acurite 606TX Sensor", "id" : 0, "battery" : "OK", "temperature_C" : -0.700, "mod" : "ASK", "freq" : 433.983, "rssi" : -0.131, "snr" : 14.394, "noise" : -14.525}

{"time" : "2019-02-24 19:20:27", "model" : "Generic Remote", "id" : 13479, "cmd" : 10, "tristate" : "01Z0XXZ100XX", "mod" : "ASK", "freq" : 433.905, "rssi" : -0.918, "snr" : 13.607, "noise" : -14.525}

{"time" : "2019-02-24 19:20:27", "model" : "Smoke detector GS 558", "id" : 1833, "unit" : 12, "learn" : 0, "code" : "50e52c", "mod" : "ASK", "freq" : 433.905, "rssi" : -0.918, "snr" : 13.607, "noise" : -14.525}

[zuckschwerdt]

Note that those values are not absolute but subject to the automatic gain in the recevier. The levels look good. The decoder will work fine with that. But the outputs look strange, not like proper sensors. Try to use CubicSDR if you can. Otherwise grab samples (rtl_433 -S all, best with more bandwidth: -s 1024k) and drop those sample in http://triq.net/iqs to picture the spectrum.

[DeadEnded]

Okay

, I took samples for a few seconds - dropped them into that site, but to be honest, not completely sure what I am looking at. I have attacked a few, but only allowed 10MB.

temp.zip

[zuckschwerdt]

Thats a clean looking band with a single transmission on it at abou 433.9M. The signal is rather long (1 second) but there is no overlap. You would be looking for multiple overlapping streak like that. Compare to https://github.com/merbanan/rtl_433_tests/blob/master/tests/prologue/02/prologue_-760_40_ch1.cu8 -- you see two sensors of the same kind overlapping (in time, but not much in frequency) and a third shorter strong signal.

[DeadEnded]

Okay! Thanks for the explanation. I will take some more samples - I only captured the constant broadcast of the rouge sensor previously. So I'll do this and also continually trigger my own sensor so I can get a recording of the overlap. Apologies I didn't realize this was the intent before. Like I said earlier - first time working with all this - little bit of a learning curve.

Cheers!

[zuckschwerdt]

Use e.g. rtl_433 -s 1024k -w grab_433.92M_1024k.cu8 -T 60 to grab 60 seconds in one piece. This will show the timing and relation between signals better. If you can use the receiver in your main computer and try CubicSDR, you will get a live "waterfall" picture like the spectrogram.

[DeadEnded]

Well, in an interesting turn... today I don't see any JSON messages generated from the rouge sensor. But my sensor is still not registering signals very well, so I ran the 60 second sample while I constantly triggered by device. The output is 110MB - so I can't attach it here - but I was able to take a screenshot and attach it.

I believe that my sensor is the hard to see small dots at 433.92MHz. There appears to be a much stronger signal (bigger dots?) sitting right around 434.00MHz. Possibly something else down around 433.73MHz... but I don't know if that yellow-ish dotting is something or just artifacts...

Anyway, I appreciate all the help! I hope the below image is visible, and you can make something of it. I apologies for my lack of knowledge and much appreciate your time and effort helping me!

• DeadEnd

note... I also have no clue what the graph on the right side represents... FYI

[zuckschwerdt]

That is indeed a strong signal shadowing your sensor. You can cut a piece of the file with rtl_433 -s 1024M -w piece_433.92M_1024k.cu8 grab_433.92M_1024k.cu8 -T 5 for upload. If you tune down you can perhaps get rid of that 433.7M should do it.

[DeadEnded]

I tried shifting the frequency and didn't get much success. I did notice that my sensor is fluctuating between 433.90# and 433.98# - so I think shifting the window might not work. I am wondering if there is a way to identify what this other signal is, even though RTL_433 isn't catching it (yet). I did try -G but didn't get anything else.

I did have another question - on my MQTT broker, I see the rtl_433 client connect and disconnect on every signal. Is this how it is suppose to behave? MQTT on my phone stays connected, as does another listener... but they subscribe - so is this normal since rtl_433 is only publishing? Normal or abby-normal? If the rtl_433 should stay connected maybe this is actually part of my problem and I didn't know it!

Thanks again! DeadEnd

[DeadEnded]

To make things more fun, at 4am today the acurite sensor began broadcasting every second again. After 4am I stopped seeing all other sensors but this one.

I think I am going to have to start knocking on doors to find out whose this is, and why it is constantly broadcasting.

[zuckschwerdt]

You might get into building a custom directional antenna and roam like a huntsman looking for prey :) Perhaps you have some success putting the magnetic foot of the antenna on a frying pan and trying to guess a direction. You need to do that outdoors to reduce reflections though. Might make a funny picture. But to really track you need to get CubicSDR or Gqrx going to see a live signal.

[DeadEnded]

@zuckschwerdt Sorry to resurrect this - but I don't know how / if there is a way to send you a message directly. I saw this commit "Fix Acurite 606TX remove sync detection (#1005)"

By any chance was this a fix to what we talked about in this thread? or was it unrelated and just a coincidence?

I have come back to trying these 433 sensors again, and I haven't gotten it up and going yet, but my initial check I didn't see any interference (but to be fair I didn't last time either). I was hoping that maybe my issue led to finding an issue and now it may be resolved - so I can start using my sensors :-)

Thanks!

[zuckschwerdt]

That was for a newer/different version that does not send sync pulses. Maybe that was a problem for your setup too. Perhaps that change will improve reliability with your sensor too.

[DeadEnded]

Okay - BTW in case I never said it before, thank you very much for all the help! I am going to try to use either the built in or python version this time around - I believe I remember you saying they should have better performance than the shell script I used previously.

[zuckschwerdt]

Sure, happy to help. The python relay has better reliability (sockets instead of pipes) if used with a supervisor. But I'll merge the native MQTT support in a few days anyway :)

[DeadEnded]

I don't know much about programming so its all foreign to me. Maybe someday I'll have the time to learn.

I see in the readme there is already an example of using mosquitto_pub... is this not working yet? Or does the native MQTT not even need the mosquitto client?

[DeadEnded]

@zuckschwerdt One question - I looked through the pull request - I see the MQTT topics for temp, humidity, etc. If I have a device (door sensor) that doesn't have any of these topics, do I need to modify one of the scripts to add it, or is there a way for the script to automatically build all the topics is finds?

[doughecka]

btw the Acurite 606TX Sensor has an area on the back of the board that a button can be installed to trigger sending the temp 'now'. I believe the same board is used for the slightly pricier temp/humidity sensors that include the transmit button. When I was testing my 606TX, I was able to repeatedly close that circuit and force the 606TX to transmit near-constantly. So it could be that there's some moisture that's closing that circuit just enough, or just a bad board, that's causing it to transmit constantly.

[DeadEnded]

@doughecka fantastic information! If I find this happening again, I will have to take my laptop around the neighbors house to find out whose it is, and see if this is what is causing it!

Thanks!

[zuckschwerdt]

The MQTT support (-F mqtt) that will be added in a few days will publish to rtl_433/HOSTNAME/devices/(TYPE/)MODEL/(SUBTYPE/)(CHANNEL_OR_ID/)KEY: value E.g. rtl_433/myraspi/devices/Silvercrest-Remote/button: 4or e.g.

• rtl_433/myraspi/devices/Prologue-TH/9/1/id: 123
• rtl_433/myraspi/devices/Prologue-TH/9/1/channel: 1
• rtl_433/myraspi/devices/Prologue-TH/9/1/battery_ok: 1
• rtl_433/myraspi/devices/Prologue-TH/9/1/button: 2
• rtl_433/myraspi/devices/Prologue-TH/9/1/temperature_C: 22.000
• rtl_433/myraspi/devices/Prologue-TH/9/1/humidity: 87

edit: forgot the "devices/" path

[DeadEnded]

@zuckschwerdt Thanks! I found the src/output_mqtt.c file that explains it in your repo... Can't say I understand all of it, but enough to make sense of it. Great work - I'm amazed with how much work people like yourself put into these projects!

[doughecka]

BTW I'm testing the native MQTT functionality, working great for me.

[zuckschwerdt]

Adding documentation or a specification is always last on the list, but I'll try to write something for our MQTT format ;)

[DeadEnded]

Another bothersome question - I got my system up and going again - waiting for the MQTT merge to try that out, but for now using the JSON pipe (since I'm not confident I don't know how to use the MQTT from your repo, and I just wanted to get it going first... but I think it is simply RTL_433 -F mqtt://localhost:1883).

Anyway - I have a door sensor with model number GS-WDS07. It is showing up as a Generic Remote, and I thought this probably doesn't matter, but thought to ask in case - does it matter?

I did see that the GS-WDS07 appears in the RTL_433.example.conf file - so I assumed it was supported and working without issue - but wanted to ask... since you've been so helpful.

[zuckschwerdt]

If the Generic Remote output has all the info you need then go with that. Otherwise disable the Generic Remote protocol and enable the GS-WDS07 protocol -- best to use a config file for that.

When native MQTT is merged the command is rtl_433 -F mqtt://localhost:1883or since localhost and 1883 are the default just: rtl_433 -F mqtt

[osborne82]

When the mqtt is fully implemented can I specify a user name and password. Would I add this to the config file?

[zuckschwerdt]

Sure, rtl_433 -F mqtt://localhost:1883,user=FOO,pass=BAR. S.a. https://github.com/merbanan/rtl_433/pull/1016/files#diff-62c9dabfb5c2a8d045a3ee4b24103c75R242

[osborne82]

Brilliant thanks

On Tue, 26 Mar 2019, 20:04 Christian W. Zuckschwerdt, < notifications@github.com> wrote:

Sure, rtl_433 -F mqtt://localhost:1883,user=FOO,pass=BAR. S.a. https://github.com/merbanan/rtl_433/pull/1016/files#diff-62c9dabfb5c2a8d045a3ee4b24103c75R242

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/992#issuecomment-476825765, or mute the thread https://github.com/notifications/unsubscribe-auth/AIRNQgTdtA2Dklq87dwPgTeHtrRFcBroks5van1DgaJpZM4bOr9a .

[DeadEnded]

So I would use -R to disable the generic remote, and then create/modify (if it already exists somewhere) the rtl433.conf with this (uncomment just the last line, or the last 4 lines)?

# Golden Security GS-WDS07 door and window sensor
#  short is 476 us + 1344 us
#  long is 1364 us + 448 us
#  packet gap 13972 us
#decoder n=gswds07,m=OOK_PWM,s=476,l=1364,r=15000,g=1600,bits>=24,bits<=25,invert

With I have to use the -X also, or is this an alternative to the above conf file change?

Apologies for the questions - trying to understand.

UPDATE: Okay, so I just ran the rtl_433 command in the shell script with:

/usr/local/bin/rtl_433 -F json -M newmodel -R -30 -X "n=gswds07,m=OOK_PWM,s=476,l=1364,r=15000,g=1600,bits>=24,bits<=25,invert"

And got out WAY more than expected...

{"time" : "2019-03-26 21:48:17", "model" : "gswds07", "count" : 19, "num_rows" : 20, "rows" : [{"len" : 60, "data" : "fffffffff694e14"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 25, "data" : "34a70a0"}, {"len" : 24, "data" : "34a70a"}], "codes" : ["{60}fffffffff694e14", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{25}34a70a0", "{24}34a70a"]}

So I think maybe it is not accurate to my sensor (revision?) or I did something wrong.

[DeadEnded]

If you haven't started ignoring this thread yet... I did clone your feat-mgmqtt branch and succesfully have the mqtt working - for the short test I have done it is working great - generates a lot of messages, but that is by design I think since you create a topic for each part of the json message.

Anyway, thanks again for all your work!

[zuckschwerdt]

Don't worry, questions help to get an impression where more documentation is needed.

Just enabling that one line is enough. In the output the code 34a70a0 identifies your sender.

You can limit the detection to your sensor and shorten the output with:

decoder n=gswds07,m=OOK_PWM,s=476,l=1364,r=15000,g=1600,bits>=24,bits<=25,invert,match=34a70a,countonly

[DeadEnded]

MQTT output support with options to

• output JSON event data to single topic
• output device/sensor info to nested topics

From the pull request it sounds like you can select a single topic or nested topics (multiple). How do you set this? Currently I am getting both :-)

[zuckschwerdt]

E.g. -F mqtt,events for just events. Longer example -F mqtt,devices=mybasetopic,events=ev/base/topic,states=foo/bar/topic. Also -F mqtt://host:1883,user=USER,pass=PW,devices=mybasetopic,events=ev/base/topic,states=foo/bar/topic.

[DeadEnded]

So my next question - is there a performance impact of using the single string vs nested? If you have multiple sensors, would using nested cause any delay due to the number of topics being published? I don't know if this is something that is easily tested or known.