This makes my point about custom firmware for me quite well. I didn’t write it, it’s off-the-shelf.
Maybe I will write my own and do discovery properly, or maybe I will just not bother with discovery. I mean I don’t have hundreds of devices and I don’t mind editing a config file and knowing I have control.
Lots of people here look down their noses and sneer at people who use discovery anyway so it’s just a matter of what works for you and what your goal is
I think it’s a mistake to make generalisms and policies from a position of ignorance, but we all have our own ways of looking at life…
My suggestion stands for future readers of this thread, if not for the OP.
Elaborate.
I refer specifically to your reply to my suggestion, nothing more.
eg: your rant includes “API” and “MQTT discovery”, and by the general manner by which you’ve coloured their use it would appear that you are not familiar with how either ESPHome OR Home Assistant actually work … yet.
Best of luck with your project.
It’ll be interesting to see how it develops.
… and I do hope that you’ve taken my comment as constructive criticism, rather than as an insult that deserves another long reply.
Exactly my point. If I need to know how one particular application or other works in order to use a protocol or API then it is not an open standardised protocol or API but a proprietary API to that particular application.
MQTT discovery is a Home Assistant specific feature that only works with Home Assistant. Therefore if I made devices that support it alone, then I make devices that only support Home Assistant and I do not want to do that.
EDIT: Granted I can make devices that support MQTT and are therefore hub-agnostic and provide MQTT discovery as a nice to have for HA.
So I added the config manually to configuration.yaml, but my switch still didn’t work.
Looking at the MQTT message flow I discovered that ESPurna was set to use “Payload”. In doing so, instead of publishing it’s state on the topic RFBridge/relay/0 with a single int 1 or 0, it was publishing it in a payload to a topic RFBridge/data containing a JSON payload with “relay/0”:“0”
So now I have the integration working with HA, I can fix the actual handler switching the light on to not use the payload… or actually put MQTT handles on the relays themselves 
I think this issue lies with ESPurna which does not update it’s config output or discovery to reflect this option being enabled.
Nonsense. Once again you profoundly misunderstand.
I understand completely the desire to not use discovery. I like to have that extra bit of control over my configuration so I configure everything manually if possible. I feel that in cases where something goes wrong I at least have a bit of knowledge about what is going on under the surface and it gives me a (albeit, small) edge in being able to troubleshoot things.
That said, one of the places I do use “discovery” is in the ESPHome area. I think the advantages of using the API make it worth the “risk” of my HA going bad or some other thing happening that prevents me from using automation to control my devices. And if HA gets turned off right now then all of my stuff will generally still function just like a normal house.
The other thing is that if I stopped using HA for some reason and went with another home automation platform that didn’t support the ESPHome API I can very easily flash the devices again using OTA and be back to using MQTT in no time.
Yea. I read up on the ESPHome API and was shocked to see people going back to binary protocols. I’ve been around long enough in software to see everyone leaving binary protocols behind. All but those who need extreme performance or those working at extremely low levels. I have scan read the documentation and understand it’s built using Google Protocol buffers and can read the headlines there and while I understand the ethos behind their protocol framework I don’t believe it is appropriate in “my” home automation.
When you have worked a few years in application support and you have been called at 3am to fix something that has failed. When you find it teaming with fancy complicated bits and bells and whistles with rubbish or no logging that makes it very hard to understand what is going on, you really, want to kill the person who made those decisions as the clock moves past 9am and people start arriving the office while the big boss is phoning you every 10 minutes “Are we there yet?”. Binary protocols are the worst case in this scenario. They are closed, blind, and there is virtually no low level intervention. You can’t for example telnet to the port and send raw commands to find out if a component is functional. You would need a hex editor or at least a test application which has all the protocol definitions. I’ve even at time copies the unit tests to a server to try and hack a component into life.
If I come home from work or the pub and find my heating is off or my living room lights won’t work and it’s freezing I want to be faced with simple, open, easy to diagnose, easy to swap out, easy to hack and easy to fix things that if needs be I can inject commands/control into to restore it or patch it till morning. I want to quickly work out which component has failed and why.
I want APIs that can be fixed with curl, telnet and netcat or PostMan in firefox. I can write JSON, XML or CSV by hand, but not protocol buffers. I want components I can bin and swap out for another from a completely different vendor in minutes or hours. I want access to the internals if I need them.
Sometimes the convenience of a “black box” component or protocol that sells you the dream of “We’ll take care of everything, just you relax”, will sting really badly when it says, “I’m sorry, I can not let you do that Dave”, or simply dies for some bizarre reason that it doesn’t even tell you about.
Each to their own and as I have control of things at quite low levels I want to retain that control where possible.
You can use esphome without their API. MQTT would satisfy your dislike of binary protocols. Move on.
I am not trolling you. You simply won’t listen. How is it ignorant to say that MQTT is NOT a binary protocol? Sure you can send binary messages, but mostly they are text.
I would like to object to hiding a post and allowing responses to it. This is hypocrisy and/or fascism. Nick is allowed to spit short sarcastic and uninformative attacks towards me, but when I reply in the kind I get flagged and my post hidden, while you still allow Nick to respond to it.
Really? Noted. I will not be editing my post, it stands as accurate and appropriate. Leave it hidden if you wish, but if you wish to apply that stick then can I suggest you apply it equally and fairly?
Nick. MQTT IS a binary protocol. While it may be vendor agnostic and an actual published protocol, it may not define it’s payload and allow you send whatever you like, it is still binary. You cannot telnet to an MQTT server and send textual operations without first enclosing your payload with a binary header/footer.
http://www.steves-internet-guide.com/mqtt-protocol-messages-overview/
http://mqtt.org/
Now, may I ask you a simple question. When evaluating a protocol for it’s suitability for your application and architecture what tests and measures do you apply to make your decision?
Hi,
While I don’t want to intervene in your “civilized” discussion I suggest to look also into multi-function devices such as Xiaomi switches https://www.aliexpress.com/item/32634498834.html, the new Hue Smart Button - not yet available https://www.engadget.com/2019/09/05/phillips-unveils-new-hue-smart-button-and-upgraded-go-lamp (these two are Zigbee) or Fibaro Button https://www.amazon.co.uk/Fibaro-FGPB-101-8-The-Button-Orange/dp/B01ITPW37A (Z-wave).
Hue and Fibaro are a little expensive, however Xiaomi switches are quite accessible. They use Zigbee (Deconz or Zigbee2MQTT can be used to receive payloads from) and I think the advantages over your initial posted solution are obvious:
Anyway, as a side note: on your 433 Mhz switch you can also press both buttons at the same time and it will send a different code (which you can assign for another action in HA such as the one for toggling a lights group). Actually, if you have 433 Mhz remotes with multiple buttons, they will send multiple codes too, determined by the formula: 2^no. of buttons - 1 (ie. 7 codes for 3 buttons, 15 codes for 4 buttons, etc).
Thanks Petrica.
I had considered the RF security issues and will evaluate that on a integration by integration basis. At the moment, for example they could turn my living lights on and off. Which while that might amuse a 10 year old for a while they’d get bored of it. Much the same as firing a custom remote through someone’s window and changing their TV channel with IR. It’s perfectly possible, but unlikely anyone will do so as there is no gain, other than being a pest. Obviously there are things I would want well secured at very least behind my Wifi.
Long press in my case is implemented on the SOnOffs as a way to send a message rather than just switch this particular device on/off. I use it to switch the group of lights, or demand one hours heating (for the heating boiler SOnOff). It’s done with C++ button debounce code here:
Zigbee (and others) I think I will leave in the “when I have no choice” bucket
I spotted the “both buttons” sends a different code. It’s nice to have, although I noticed the MQTT message was slightly different, although this might have been due to me having “Payload” enabled in ESPurna. (I’m not yet settled on ESPurna, it was a quick install to prototype things).
The greater damage is that, if the perpetrators start messing with the lights at 3-4 AM, then wife/girlfriend will make you sleep on the couch for countless nights 
Joke aside, the security problem is more likely that some evil persons will know when you are at home and when you’re away and could make your home a target based on that. Anyway, you can reduce this risk by: i) sending garbage RF codes all the time (when either home or away) at say each 15- 20 minutes and ii) sending the real codes also when away (and even start tv/radio) in order to mimic occupancy.
I started with the same RF switches as you have in the video but moved to Xiaomi Zigbee switches (the one mentioned above for multifunction and https://www.aliexpress.com/item/33053485189.html for regular control of the lights) because, aside from security concerns, they feel more premium and the click made while pressing is quite pleasant 
My other 433 Mhz devices (PIR and open door sensors) are using the gateway code from this project which I think is worth checking (switches too, before change to Xiaomi): GitHub - 1technophile/OpenMQTTGateway: MQTT gateway for ESP8266 or ESP32 with bidirectional 433mhz/315mhz/868mhz, Infrared communications, BLE, Bluetooth, beacons detection, mi flora, mi jia, LYWSD02, LYWSD03MMC, Mi Scale, TPMS, BBQ thermometer compatibility & LORA..
I also use some very cheap 433 Mhz power plugs, but not for sensitive devices or for inductive loads (mostly for mosquito repellent solutions and for aroma therapy 
)
One other reason for giving up 433 Mhz switches is that some of the HD CATV channels provided by the ISPs where I live are using the 433 Mhz frequency and each time I pressed the switch, the TV would scramble for about half a second, which is quite annoying (although I hardly ever watch live TV). PIR and open door sensors don’t seem to interfere with TV.
In addition, I use Florian’s code above for environment sensors (each room is fitted with an ESP8266 + DHT22 + LDR to get humidity, temperature and light levels in HA), IR gateway (for controlling split AC and receiver as sometimes the bloody HDMI CEC is failing to turn it on or off), wireless relay (for heater control) and SMS gateway (for sending alarms to phone or control devices from phone even if there’s no internet available).
I like that idea. Hide in the noise
Does the Open MQTT gateway support zigbee devices out of the box?
What attracted to me to 433Mhz is just how low power they can be made. As I understand it the switch is both the actuator of the signal and the power switch, so it’s only connected to the battery when the switch is pressed.
Being in the UK, while I haven’t actually looked, the chances of there being a neutral wire in a light switch box is next to none. I did look at some of the “leakage transformer” ones that Amazon sell, but they are like £70 and I don’t think I would trust they would use an open protocol over Wifi.
On security I spotted some interesting attack vectors I hadn’t considered. If someone uses a jammer or disrupter to upset your Wifi devices and they disconnect they can launch an access point and try and trick your devices to connect to them. But it left me wondering that with PSK my device will still send it’s sync requests encrypted and their fake access point will not be able to decrypt it and continue faking my AP. I believe they can still crash things like ESPs with exploits recently discovered, but I still don’t think they can gain control of the device. But… I’m not an IT security expert, just a conscientious developer. I know enough to be fairly safe and clued up and also when in enterprise applications to refer to a proper pen tester.
Unfortunately not yet (Florian said that he intends to).
This Zigbee switch doesn’t require a neutral wire https://www.aliexpress.com/item/4000116621307.html
I don’t have a neutral wire at my home either but I use one of these (actually the two buttons version; the second button doesn’t need to actually control a device and can be used as a wireless button). Before this I had a RF switch associated to a RF relay for the bathroom light but it wasn’t very easy to control it (RF switches have three modes: momentarily, toggle and latched; momentarily mode works only as a ring device; in toggle mode, HA doesn’t have a clue what is the state of the light and I had to use a light sensor for this - acceptable but not perfect; in latched mode, HA was able to accurately get the state however it required pressing one button for on and one other for off, which is really not practical).
It’s a pity that nearly all of the smart devices these days are designed to be wireless and completely ignore the good ol’ copper (not to mention about the wifi devices that need a constant connection to a remote server that might leak the credentials or completely shut down service like Google did with Nest). At least the 433 Mhz gateway from the OpenMQTT works on Arduino + Ethernet shield so no problem if someone kills the wifi (in fact this RF gateway running on Arduino Mega + Ethernet shield is the most stable smart device I have). I think that the environment sensors (DHT22 and LDR) can be put on Arduino to use the cable connection too (currently I have them running on ESP8266).
Working out what state a “switch” is in. This is why I like getting into the lower levels. Obviously the relay knows what state it’s in. You look at the register for that pin and it’s state.
Then it’s a choice of, broadcasting/publishing your state to the network periodically and/or providing a way for things to query your state. I actually use both in various ways. So both “push” and “pull” states. It depends on what it is and why I need to know it’s state. If it’s something I want to log/graph the state off, I have it push/publish periodically to a data logger. So an accurate record is kept regardless of “how” or when it got switched/toggled. If it’s something I might do less often or is more “transactional” I literally check the device state before I command it and verify it’s response to that command if need be.
EDIT: Not apparent from my video the lights coming on is guaranteed by the lighting controller, if it receives the MQTT message to turn them on, it will not give up until they are on. Even if you switch them off at the wall and back on some time later, it will attempt to switch them on as soon as it sees them! I “can” vary the amount of time over which it does this.
This mechanic is a side effect of using my system designed for heating control to control lights. It has it’s downsides. Manually switching off any of the lights and the lighting controller will switch them back on again. With heating this isn’t a big deal, I want strict transactional control of the boiler state. But the heating system expects the demand for heating to be renewed periodically. This is akin to me having to press the light switch periodically or it would turn the lights off. So get round this I set the time the demand for lights is valid to something like 10 hours. So once you switch them on, it will ensure they are on for 10 hours. I have a few potential fixes, but I think I might move to MQTT event based control of lights.