433 MHz buttons

[MikeP 4 MPP]

Hi folks, I hope everyone is well.

I'm looking at adding a bridge to the MPP devices for receiving RF 433MHz signals with the idea of sending them to an AM Server as a detected button press as an event - I figure the swiches could be battery powered, monitored by a powered MPP for a very quick response.

Ideally I'd like to use purchased buttons, found some on alibaba - I don't have them yet - they're described as unencrypted learning remotes.

I'm trying to figure out the best way to handle these - which hardware and which libraries make sense here.  I looks like there's one called "radiohead" that is a generic data send/receive library for 433MHz devices.  I've also got some HT-12E and HT-12D for encoding/decoding addressed (8 bit) signals that carry 4 bits of data, but I'm not sure if/how they work with the learning devices.

Seems like there's a jumble of choices here I'm still trying to navigate...

Has anyone played with any of these?

[DougC]

Hi Mike. Yes I've dabbled with some of this. I got some Qiachip ASK transmitter and receiver modules from China. I also found the Radionhead libraries and created some Mpp compatible code from a couple of their examples. I used their RH_ASK library.  Never looked at the HT-12 chips.

IIRC I got the receiver part to work but never the transmitter. The breadboards then got put away , waiting for more inspiration, so I can dig them out easily.  I had originally hoped that I'd be able to intercept and spoof the RF of my wireless home thermostat.

On a different front - I noticed there is recently a V3.0.0 of the esp8266 library. I guess it will create as many problems as it might fix.

[MikeP 4 MPP]

For buttons I grabbed these: https://www.aliexpress.com/item/33019278968.html?spm=a2g0s.12269583.0.0.53171a6aWOsAwI, but they're probably still a few weeks away...

Just found the same ones on amazon (for 3x as much!), these have an EV1527 marking:  https://www.amazon.ca/Wireless-Control-Stickers-Transmitter-Regulate/dp/B07C5N94LR/ref=sr_1_4?dchild=1&keywords=433%2Bbutton&qid=1621885123&s=hi&sr=1-4&th=1.

Tracked down the specs for the EV1527:  https://www.sunrom.com/get/206000.

It claims 1uA standby current, so hopefully the battery will last a long time.  Looks like they'd be a better choice than the HT12 D/E chips so those are probably going to go to waste.

I've also got the standard 433 transmitters & receivers that should work with an arduino (or an ESP8266): https://lastminuteengineers.com/433mhz-rf-wireless-arduino-tutorial/.

I'm hoping the receiver data output is open collector so I don't need to modify the signal from 5V to 3V3...  but at least I can power it from the wemo minis board.

Once the switches arrive I'll see about using that radiohead library to receive and process the button clicks.  Fingers crossed!

I'll have a look at the new library version, but I'll probably wait for 3.0.1 or later before I release anything - let them get the first problems out before I spend too much time testing.

[MikeP 4 MPP]

Got the buttons (4) yesterday and it turned out to be pretty easy - found an old (>9 years!) arduino library that supported the EV1527 and adapted it to the ESP8266.

Used a wemos mini, powered the 433 receiver with +5/GND and a voltage divider for RX (10K/20K) to bring the voltage down, fed into wemos D2 (GPIO4).

The buttons worked right away, each with a different 32 bit code.  Not sure how the learning works but this is good enough for me for now.  Reliable range is < 1m, it's worked intermittently out to 3m.  AM gets the press notice pretty much instantly.

It's in MppEV1527.ino (I'll publish in the next update).  It's an MppSensor device that turns on when a button click is detected and off when it's released (with a tunable delay to filter the repeats, 200ms is working well).  It puts the button id into the device's message.  For rule actions it'll work with a "WhenDevice" trigger plus a "DeviceMessage" condition to distinguish (and ignore) different buttons.

Next steps will be to solder it up and add an antenna to try to increase the range.

[sergey]

Hi everyone! I appreciate the idea of 433MHz devices , there is only one significant drawback using of them in my living area - oversaturating. These damn kitchen manufacturers has made wireless remote control for cooker hood, and this remote control is based on 433Mhz receiver. Due to the high abundance of remote control for barrier control for home garage , my cooker hood was started to work in unpredictable time.  I re-coded it several times, but anyway a new remote appeared to be tuned with the same code and i had to switch remote of my hood off eventually. The remote control is based on PT2262 , i haven't played with EV1527, i hope it's gonna be better.

[MikeP 4 MPP]

So far it's working - soldering the board and adding an antenna has given me a range of about 10m-20m.  The input is pretty noisy!  But the code filters it out so it seems to work well despite any other signals.

[MikeP 4 MPP]

Fiddled a bit more with range and antenna length...  found that range varies during the day and by transmitter switch (manufacturing tolerances or battery power?).  The internet shows different coiled antenna lengths and winds, and maybe it works if both the transmitter and receiver have them, but with these switches I got the best result with a 35cm (ish) straight wire.  Theory says 34.6cm so not an unreasonable result.  I tried 17ish cm but it seemed to work better as I went longer.  In home 10m seemed to be the max with my worst transmitter, 15m for my best.

[st...@marshallarts.com.au]

Hi Mike,

Thanks for this, sounds good.  I needed something to tinker with recently, and thought I might replace a couple of MppSleepers with these.  Nothing wrong with the sleepers of course, but it's just a bit more satisfying for the light to come on almost as soon as the button is pressed, rather than 3-5 seconds later.  Anyway, I bought some of those buttons from AliExpress.  And I bought a 433MHz receiver module from them too - this one here - https://www.aliexpress.com/item/32980820915.html?spm=a2g0o.9042311.0.0.7b154c4dnaMsJD   It's not identical to the one you mentioned, but very similar I suspect.  It is not entirely clear to me whether the receiver should be powered from 5V or 3.3V, but I'm leaning towards 5V.  Anyway, I have tried both, but I can't get anything to happen either way.  When powering it with 5V I see about 4.6V between pins 1 and 4 on the receiver, and have implemented a voltage divider for the data out pin, so that the Wemos Mini should only see 3.3v approx on D4.  I have a piece of wire about 17cm long soldered to the ANT connector on the receiver.  When it is all powered up and it's essentially idle, my multimeter shows a voltage wandering around all over the place on D4, does that sound right? I've seen voltages from 1.35 up to nearly 2.0.  I am a software guy, so not at all strong on electronics and circuitry, so I am bumping into the limits of my understanding here.  I'm talking to it with MppArduino on a laptop USB port, on the assumption that I should see any activity there if it happens.  If I do a READ of GPIO4 in MppArduino, it always returns HIGH.  The button appears to be doing something - its LED indicator lights when I press it, and it is essentially zero distance from the receiver.  Any suggestions for what to try next would be welcome.  Thanks.

[st...@marshallarts.com.au]

A bit more info... a friend of mine runs an EMC testing lab, so I took my buttons there and activated them with his spectrum analyser, just to make sure they are doing something.  They are - one of them was bang on 433.92MHz, the others were transmitting at about 434MHz.  Didn't have time today to put an oscilloscope on the data pin on the receiver module, but that's the next step I guess.  The ESP8266 module I have looks for all the world like a WEMOS D1 mini, but is not actually labelled WEMOS or LOLIN.  It DOES have "D1 mini" stamped on it.  Anyway, as I said above, the 5V/GND connections on the module seem to be providing only about 4.6V - not what I would have expected.  So the question arises - is it possible that 4.6V is just not enough to drive the receiver module?  I found another type of 433MHz receiver today at a local hobby electronics store, and I grabbed one but can't get that to work either.  It also runs at 5V.  I was sort of hoping that this was going to be more or less plug-and-play, but not so far!

[MikeP 4 MPP]

Hi Steve - I'm finding these modules to be a bit finnicky too - the range I get varies from day to day without touching a thing...  I get the best responses from some EV1527 buttons - a few meters range (5m on a good day), where as my PT2262 transmitters usually won't work for more than 1m.  I've also tried swapping antennas and I'm finding my non-superheterodyne receiver is getting better range than the more expensive one... go figure :(.

You haven't mentioned what firmware you're using, that depends on the button type as they'll send a very specific signal that needs to be decoded.  As I mentioned, I have the EV1527 and the PT2262 variants available.

Once you get them running you'll want to use MppArdinuo to monitor the signal - there are statistics shown that should at least let you know if the radio is working (sounds like it is from the voltage variations).  The counter values should change when you press/hold the buttons.  The main tuning is to set the leading pulse width, the firmware uses that to decide whether a signal has started.  The other setting is the noise pulse width, you can increase that to improve rejection/stability once you know the main leading width.  I've got tuning tips in the comments on both sets of firmware.

The specs for your receiver look like it'll take 2.2-5V, I'd be tempted to try using 3V3 from the on board regulator for stability as I think these things are pretty susceptible to noise.  I'd also try 5V just to see if more power helped.  I'm struggling to get the distances and repeatability that's reported by other users of these devices...  While the buttons work well, I picked up a sonoff DW2-RF that's also EV1527 but it's range is about 1/2 that of the buttons.  I suspect the noise might be power supply related but I haven't tried running a separate supply/regulator yet.

[st...@marshallarts.com.au]

Hi Mike, thanks for the reply.  I'm using the MppEV1527.bin firmware, which I thought was the only one available.  But when I look at the MppEV1527.ino source, I can see a class called PT2262Server, so now I'm confused!  My buttons are very similar to the ones you linked to above, but with slightly different colours.  But they say they have the EV1527 inside so I think they are functionally identical. When I click "Versions" in MppArduino the response is

• 2022.02.03 22:10:11.111 MppArduino 1.12.0 / MppEV1527 2.0.0

Does that look right?  If not please point me to the right firmware.  If I have the wrong firmware it's no wonder nothing is working! :-D

[st...@marshallarts.com.au]

...and where do I see these statistics you mention, in MppArduino?  Is that just in the properties, if so which ones?  Nothing seems to change there, ever.

[sergey]

Hi Steve, i've never seen the exact module you've experimented with , but toyed with similar one. I have to mention that the transmitter has EN contact that allows sending data if EN is connected to VCC.  Usually they are tolerant to 5V , but sometimes you can buy 3V only version. For receiver module the VCC and GND are responsible for feeding and  two DO  are connected together and have a voltage range 3-5V . Accordingly to the datasheet the receiver  chip is  SYN500R. And it's better to have the length of antenna   like this:

As for Wemos part - i  don't understand completely what you would like have seen on D4 ? First of all you need to switch D4 for reading data - pinMode(02,INPUT).  The second - don't use GPIO2 (D4) for input due to it's pulled up for Wemos and connected to internal LED . The third - 1.35 it's a bordering voltage that might be mean as HIGH for this particular circuit.

Wemos works quite good with 4.6V .

[MikeP 4 MPP]

MppEV1527.bin should be correct for EV1527 switches, there was a copy/paste typo in that file, sorry about that, fixed.

You need to use MppArduino.jar to see the statistics - noise, rejections, etc - they're displayed to the console.  If you've got the latest MppArduino you can use the TCP console remotely, but too much TCP traffic can interfere with the RF interrupt handler.  I set "Period" to 5s for a reasonable update rate of the statistics.

Another trick I use is to set the LedPin so that it shows visually when a valid signal is received.  For the wemos board I re-use the WifiPin, GPIO2.

Quick reminder, D4 (as marked on the wemos and nodemcu boards) is GPIO2!  https://sites.google.com/site/mppsuite/esp2866/pinouts

[MikeP 4 MPP]

Serg is right, you'll probably have issues trying to use D4, I usually use D2 (GPIO4) for input signals.  The pin naming is really frustrating/confusing, I don't know why they did it that way...

[st...@marshallarts.com.au]

Hi Guys, thanks for that.  Wow, so D4 is not GPIO4!  That's a trap for the unwary, that's for sure.  OK, so I had RxPin set to 4, but the wire connected to D4, so no wonder it wasn't working.  Moved the wire to D2, and now something is happening.  A second or so after pressing the button I got these:

• 2022.02.04 07:23:34.433 Rejected data end pw=539, outside of 852-1412!
• 2022.02.04 07:23:18.248 Rejected data end pw=343, outside of 940-1564!

Doesn't tell me much, but I'm sure it means something to you Mike.  These messages keep appearing (with different numbers) even though I am not pressing the button.  My complete properties at the moment are as follows:

• 2022.02.04 07:31:22.089 {"MinPulseWidth":"250","RxPin":"4","ip":"192.168.1.104","MaxPulseWidth":"300","WifiPin":"2","gw":"192.168.1.1","CycleRecovery":"5","BufferSize":"1024","NoiseFilter":"25","Delay":"250","ButtonPin":"0","NameMppSensor_500291fe2405":"Button Listener","nm":"255.255.255.0","Version":"MppArduino 1.12.0"}

At least something is happening now, wen it is listening to the right pin!

[MikeP 4 MPP]

Cool, that's what you should be seeing.  There tends to be a lot of RF noise in general, what you're looking for is the pulse width (PW) when the button is pressed.  In the above cases it's 539 and 343, but watch for it when you're pressing a button.  I'd suggest holding it < 12" away from the antenna at least until you get an idea of the range.

Start with MinPulseWidth=200, MaxPulseWidth=500, then narrow it around the typical pulse width you see when you press the button to better reject noise.

[st...@marshallarts.com.au]

Woo hoo, just saw my first button press event!  Yes there does seem to be a LOT of RF noise around, because the messages keep on appearing continuously in MppArduino.  So, the message in my server log says:

.... 192.168.1.104:8898 Said 'EV1527 755081 pre=329 pw=10910 pw/pre=33'

So I assume the 755081 is the code that is coming from the button?  I think it is, because I tried one of my other buttons and it changed value.  Wow, progress!  Thanks.

And Sergei, yes this receiver did come with a coiled antenna.  I stayed with a simple dangling piece of wire because Mike said it worked for him, and it's a bit simpler to arrange.

I've just implemented my rule, and my light is now coming on and off INSTANTLY.  Thanks guys, this is great.

[MikeP 4 MPP]

Nice :).  Yes, that value is the code for the button.  In AM you can setup rules to look for codes using DeviceMessage with a WhenButton trigger, or you can set comma separated values in the property "Codes" which each become separate devices in AM that you can use to trigger rules.

I've been working on tuning that seems to improve the range quite a bit, I'll send you the binary separately.

[st...@marshallarts.com.au]

Great work Mike, thanks.  I like the sound of that Codes mechanism, will definitely try that.  I was hoping to be able to velcro this thing onto its USB power supply in a power point where the 2 buttons I want to use are reasonably close.  But there seems to be so much interference that it is making the button presses unreliable.  If I connect to its IP with MppArduino it is going crazy with messages.  Rats.  I wanted to avoid cables trailing around, but looks like I might need to have a longer USB cable and get it away from the AC.  More work required!  Maybe I should try the little coil antenna too.

[st...@marshallarts.com.au]

One other thing that stumps me a bit... in those Rejected Data messages in MppArduino console, why do the values for the range vary all the time?  When I looked (briefly) at the code, it seemed to me that they should always be values from the properties (or calculated from them).  But they seem to change for every message.

[MikeP 4 MPP]

Those are a bit tricky.  EV1527 starts with a "sync" positive (1) pulse, that width is checked against your min/max pulse values and ignored if outside the range.  If accepted it becomes the base pulse width.

Then it's followed by a negative (0) pulse, if it's correctly 31 (actually 28-34) times the sync pulse the signal is considered synced.  Then each data bit is a positive pulse followed by a negative pulse, total period of a multiple of 4 times that initial sync pulse (with some variation allowed, I use 1/2 to 1 1/2 the original width).  Since that initial sync pulse varies slightly, the acceptable data pulse widths vary too.  If any are found out of range the signal is dropped and the device will wait for another sync.  The key number to watch for tuning is the "pre" pulse width of each accepted sync signal, that's the range you'll want to use for min/max.

[st...@marshallarts.com.au]

Ah, interesting.  I thought it must be some sort of dynamic/adaptive thing like that.  Things get quite complicated down where the rubber hits the road!

I've tried all 4 of the buttons I bought, so I could see what their codes are.  Some are detected with longer codes than others, does that indicate that my tuning parameters still need adjustment?  I would have thought that the codes would all be the same length.  One of them is 6 digits, one is 7 digits and the other two are 8 digits.  And I think I've just noted that the one showing as 6 digits does not seem consistent with its codes, i.e. not always the same code.

I suspect that USB plugpack chargers are probably quite noisy.  I was hoping to just velcro this little gizmo to the plugpack and leave it parked in a power outlet, but that seems to increase the stream of rejected messages quite noticeably.  So I will try a longer USB cable and get it further away from the plugpack, and see if that helps.  I wanted to avoid cables trailing around, but you can't beat the laws of physics!  :-\

[st...@marshallarts.com.au]

More and more interesting....

I just tracked down a specification document for the EV1527, and it all makes good sense - it has to or it wouldn't work!  But I see no mention of a "standard" bit rate, so I assume the transmitter can send the bits at whatever speed it wants and the receiver is required to deduce/calculate the bit rate by tracking the signal, as Mike's code does.  That makes it nice and easy for people designing transmitters.  Not quite so easy for the receiving end!  Especially in this case, where it might have to accept data from multiple transmitters.

And re my button that sends only 6 digits and seems inconsistent - I think it might just be a flakey one, so it will be put aside for now.  As there are a total of 24 bits of data sent, I'm guessing that the value put into the Message field is the decimal value of the bit pattern received, is that right?  I've only seen decimal digits, and that would account for varying numbers of digits in the reported code.  I guess I was sort of expecting hex digits or similar, so that the code would always be the same length.  I doesn't matter either way, I just like to know what's going on under the hood!

[sergey]

Good news! ) Yep, any antenna will work , the construction I mentioned is only more effective for long distance(up to 160m). And , yes, all these are pretty noisy staff. The better value for connection speed is  833 bit/sec, so the durations of logical levels for the transmission of one bit has to be  400 and 800 μs. These  conditions would give you most stable connection between transmitter and receiver.

As I told before 433Mhz is very noisy range , in my home I barely could use it due to large amount of alarms or remote controls and etc...

So I decided to move to Lora . If I have enough patience I'll show   you MppLora bridge with up to 1km long distance.))

[st...@marshallarts.com.au]

Thanks Serg, I will continue adjusting the timings a little, but things seem reasonable now.  Mike's firmware seems to be detecting bit durations around 340us with these buttons.  I don't think I need 1km range!  ;-D

And Mike, I have put 2 button codes into the Codes property of my button listener, but I don't see any new devices on my AM Server (did a refresh) and it isn't clear to me how to refer to them for rule-making purposes.  Guidance requested please.

[MikeP 4 MPP]

That's right, the bit duration tend to wander a bit so the device uses the start pulse to set the timing for each new sequence.

By loosening up the restrictions and filtering more noise in that latest MppEV1527 version I was able to get a significant range increase, from 3-5m to maybe 10-15m including between floors it's too cold outside to try any further :).  I'm still tweaking it but if anyone else needs an early copy before I publish let me know and I'll send it along.

Yes, the codes are 24 hex bits, I send them as decimal values so they'll be shorter if there are leading 0's.

Sometimes noise will clobber a bit or two and an incorrect code will be read.  Unlike the PT2262 format there's no error correction.  Whether it matters depends what you're doing - if you only need a signal you can just look for on/off, but if you want to distinguish between buttons you need to watch for the values to change.  The buttons usually repeat the sequence a few times so incorrect values can be ignored and the next one will show up correctly.

To get the added buttons you should be setting the "Codes" property, for example setting Codes=1,2,3 will give you 3 additional devices, "MppSensor_MAC_1", _2, and _3, where MAC is the wifi device's wifi/MAC (UID).  Then you can use them in WhenDevice triggers with "on" indicating a button press has been detected.  You can of course rename those devices, I just give them the default name to start.

[st...@marshallarts.com.au]

Thanks Mike.  Yes, I hadn't restarted the Wemos after setting the Codes property - after doing that they popped up just like rabbits out of a hat.  All good.  There are often long gaps between my tinkering sessions, so I forget these things.  You'll be old and forgetful one day too! :-D

I was going to ask about signal propagation too, but I think you have answered it.  I was thinking that at 433MHz there would need to be almost line-of-sight between transmitter and receiver, but if you are getting it to work between floors then obviously not!  One of my buttons is inside the front door and my receiver is in the front room - it almost has line of sight but not quite.  It is working but not 100%, so I think maybe some more timing tweaks might be in order there.

Too cold outside eh?  We are having a hot spell (another one) here in Western Australia - it's 11pm and it's still 23.5° C !  Maximum was just under 40° C today.

[MikeP 4 MPP]

Ok, updates to MppEV1527 and MppPT2262 have been published.  With a pair of straight 17.3mm wires, one on antenna and one on ground, I'm getting a range limit of nearly 20m / 2 floors.  The EV1527 seem to work a bit better than the PT2262 which gets maybe 15m / 1 floor (but a lot better than the first code version).  I'm getting the best results now with a superheterodyne receiver, almost 2x the range of the cheaper non-superheterodyne version.  I've fiddled a bit with a bare receiver connected to the wemos board, it works but not as well as when using a 10uF and I think a 100pf pair of caps across the 5V pin to ground.  When I get a chance I'll try the coiled antenna - probably when I replace the old receiver with a superheterodyne on my second antenna board.

[st...@marshallarts.com.au]

Good work Mike.  I think that should be 17.3cm, not mm.  And what's the idea of the caps?  Are they for noise reduction?  (My electronics ignorance talking again).

[st...@marshallarts.com.au]

Another intriguing thing that I've noticed with this - I believe I've seen a few occasions now where the buttons seem to work MORE reliably when MppArduino is connected to the MppEV1527 device via wifi, than when it isn't. Just saw another instance of this - pressed a button that is probably less than 1 metre from the receiver 2 or 3 times and the light did not come on.  So I connected up with MppArduino, and it then worked on the first attempt!  Is this just coincidence, or is there something meaningful in this?  It seems counter-intuitive - if anything I'd expect the MppArduino connection to put more load on the Wemos Mini, and possibly have a negative impact, not positive.

[MikeP 4 MPP]

Right, 17.3cm!  And yes, the cap's are supposed to help reduce noise introduced from the power supply when hooked up to loads like the ESP.

I'm thinking coincidence for MppArduino if you're using the TCP console, and yes, I would expect more interference too as the wifi interrupts would through off the timing of the signal interrupts.  Over USB it would make sense as often the PC's power supply is more stable than the low end USB power adapters I'm using.

For me the RF is a bit flakey, differing from day to day...  since I don't have an oscilloscope to check I usually shrug it off to solar storm driven interference...

[st...@marshallarts.com.au]

Another observation re interaction with MppArduino...

With MppArduino connected via wifi, I just pressed one of my buttons 10 times, and none of the presses turned the associated light on - not one!  This button is only 1m from the receiver.  According to the MppArduino console every button press was seen and decoded correctly by the MppEV1527 device, and it seems very RF-quiet just now, because there are almost no spurious/rejected signals being reported.  So then I looked at the log in my AM Server tablet, and not one of the button presses had been seen by the server - 0 out of 10.  I would have thought that if MppArduino caused extra load on the EV1527 device, it might just delay the generation of the event for AM Server.  But this seems to have prevented the generation of the events altogether.  Does this sound reasonable, or is something not right?  I should mention that this is my custom build of the MppEV1527 code, which reports the button codes in hex instead of decimal (so they are always 6 characters).  It seems to work fine, but I suspect there are some internal differences from the published MppEV1527 because of differences in libraries - the binary is about 20k bytes smaller than the published one.  Anyway, I then closed MppArduino, and the first button-press turned the light on!  So this seems completely the opposite of what I thought I was seeing in the earlier post above.  Very intriguing.

[MikeP 4 MPP]

If you're not seeing events in the AM log, the MppDevice event isn't reaching the AM server.  This is either a network problem or that AM isn't subscribed to the device.

Events from MppDevices are sent directly to AM instances that have subscribed - my guess would be that you restarted the MppDevice but didn't wait long enough for AM to find and subscribe to changes.  Does that sound like it might be the issue?  AM resubscribes every 30s (unless you've change the default refresh timer), but you can force it on AM using the refresh command on the device in the list.  A restart of the MppDevice of course flushes it's subscriber list.

If you're sure AM is subscribed but you're still not seeing the events in the AM log you may want to try rebooting your router first before trying to do much debugging.

In MppEV1527 I usually set the LedPin to the WifiPin so that every press of the RF button causes the LED on the ESP8266 to light - when you've veen saying "turn the light on" I thought you meant that LED that confirms a button was received :).  I see now you mean a separate bulb.  I assume you're using rule to toggle when the button code is received or when that code device turns on?

[st...@marshallarts.com.au]

Ah, I think you might have nailed it Mike.  I refreshed the device on AM server and saw the Subscribe request.  But then I watched for several minutes and saw no further Subscribe requests in the log.  It was quite a few minutes before another one appeared.  This could explain a lot!  But I looked for the setting in AM server and I can't find it.  I thought the logical place was AM Server settings, but I can't see it there.  In Preferences, the property called Update Frequency is set to 30 seconds, so if that's it, it is not working for Subscribes.  I do see GetState messages about every 30 seconds, but after watching for a while the Subscribes are definitely only happening every 5 minutes.  I also recall seeing lots of Discovery messages previously, but that might have been before I flashed my binary - I'm not seeing any of them now.  Anyway, if I make sure the AM Server is subscribed, it all works a LOT better.

Yes, I have toggle rules tied to the button codes.  I've tried setting LedPin (and clearing WifiPin), and I like the effect.

I'm actually thinking that I might get a couple of the exact same buttons you mentioned, Mike.  The ones I have are not identical to yours, I just liked the look of these ones slightly better.  But I've discarded one of them already because it wouldn't do anything unless it was within about half a metre of the receiver, and its batteries are fine.  The pulse widths seem to be around the 320-360us range with these, whereas yours were around 250 I believe.  I know that shouldn't make any difference, but it's possible that yours have slightly better RF characteristics - more consistent pulse widths across the whole message maybe?  Better range?  Anyway, when you are only paying about $2 per button, I guess you gets what you pays for!  They are cheap enough that getting another couple is no big deal.

[sergey]

Have you checked your device is not in "ignore list" ?

[st...@marshallarts.com.au]

Hi Serg, no it's not in the ignore list.  I wasn't even aware that option existed until now! I'm sure that what I saw was because AM Server had not yet subscribed to the MppEV1527 device.

[MikeP 4 MPP]

Oops, I had to check my code.  That's right, it's every 5 minutes, not every update.  MppDevice's keep the subscription alive for 10 minutes so AM renews every 5.

My black round buttons have a pw of around 300, I'm seeing a range 275 to 320.  I have a sonoff RF door sensor (which is useless IMO, it only notifies on opening) that has a pw of 260-270.

The last firmware code tweak was to be more tolerant of noise on the sync signal (which is 31 *  the duration of the pw) which made the biggest range difference - so yeah, I think the shorter the button's pulse width the better, it increases the chances of finishing without noise.

I use a min/max of 200/400 for mine, you might want to try a max a bit higher just in case if your PW is longer.  

I'm using a NoiseFilter of 100 - too big and the signals start to get missed, but smaller doesn't seem to help much.  I think the default is 25, it might be worth playing a bit to see.  NoiseFilter strips (combines) short pulses into the longer one around it, and there's some built in filtering of very short pulses because of the way the ESP8266 interrupts work.

[st...@marshallarts.com.au]

OK thanks Mike, all good.  I wasn't aware of the subscription mechanism, but I am now, so I'll be able to ensure the subscription is alive if anything odd happens.

And I've just realised why I'm not seeing any spurious/rejected signals - in the source code the Serial.printf statement is commented out!  Hadn't noticed that.  I'll think about whether I want to reinstate it.

[st...@marshallarts.com.au]

And one other thought - would it be possible to indicate in AM Server whether a subscription is known to be in effect, for applicable devices - an icon or something?  I'm guessing not, or it would be doing it already.

[MikeP 4 MPP]

Right, if AM knows it needs to subscribe it would do so, no need for an indicator.  The situation is so rare I haven't spent time trying to figure out a way around it - it only happens when an MppDevice is restarted which is only when doing development/testing - an AM or network restart causes AM to resubscribe immediately.

[st...@marshallarts.com.au]

Yes I get that.  I think I've wrung all I can out of this thread, so let's leave it at that.  My mental picture of the MppSuite now has a few less holes in it!  Thanks for all the help, again.

[st...@marshallarts.com.au]

One minor question that has just popped up with my EV1527 listener.  I had a power fail a little while back, and ever since then the listener is showing the blue light indicating its wifi status I think.  I'd prefer it didn't do that, and I had definitely found a way to turn it off back when I set this up, but I have forgotten what I did!  I've tried clearing the WiFiPin property using both the web page and the console, and it clears the property, but when I restart the device to put the changes into effect, it comes back again - the WiFiPin property that is - it's set to 2.  What am I missing here?

[Mike P 4 MPP]

Sounds like you want WifiActive - you can set the state the LED should show once wifi has been connected.