Holding reset and releasing never worked when I tryed to flash from the web, it was nearly impossible to guess the correct timing so the easy way was just sent
{“cmd”:“erase”} with the retain flag set and it took the board back to defaults. as soon as it done a reset loop. nice and easy…
That would have been the next suggestion, or more likely an init 
so well done. And I assume that the gateway discovery is still there for you, as it was created by turning the discovery on and issuing a restart with the commands I suggested above.
BUT PLEASE delete the retained erase message through MQTT Explorer, as otherwise this command will be resent every time the gateway restarts for whatever reason, and all saved setting will be erased over and over again with every restart.
Could it have been that you also sent the restart message above as a retained message - hence actually causing the continuous restart loop, as a new restart was issued every time the gateway has just started up again? 
The thing to remember, with any OMG gateways, is that after a later gateway name change, discovery must be enabled again, if it is not still in its initial 30 minutes window, and a restart must be issued. This allows the gateway to be re-discovered under its new name - otherwise it will just be disappearing in HA with the old name discovery after a name change.
That is the bit of info I did not retain while reading the help and docs. I though once it was setup it was leave and forget (and I did forget) but when the new board arrived I just followed suite. Install from web. connect to hotspot and configure. wait forr HA to find new mqtt sensors and all was happy. Once it found the new 433fsk it did not work out as planned but with you help both 433ook & 433fsk are now happy in HA.
Now to reconfigure all the sensors again.
Cheers @DigiH
You’re welcome, and glad to hear things are all up and working for you now.
Just with the retained messages, maybe you should look to see if there are other retinaed messages which might cause issues for you.
In general no command message should be retained, unless specifically stated to do so. With OpenMQTTGateway the only message which needs to be retuned, that I know of, is the white- or black-list for a BLE gateway.
All the best 
It all took a nose dive again today. I removed power from both devices and reflashed one at a time and started from scratch by Configuring them from initial hotspot config on mobile phone.
I started with the ook device and HA installed it and the weather sensors as it should.
I moved onto the second device “fsk” and followed the same routine Configuring it from initial hotspot config and just like with ook HA found the device and sensors and everything looked great. Both devices showing and responding to what ever setting in HA I adjusted.
A little while later after trying to make a new sensor in yaml I restarted HA and the ook device was all greyed out and not responding to anything.
5 restarts of HA later they both seem to be back working again. Not sure if this is now a HA problem as both sets of mqtt sensors were always working (weather on ook & oil watchman on fsk)
On a side note one of the lilygo settings has a typo in it. it shows Lilygo Internal Temo instead of Lilygo Internal Temp.
I do not know who is responsible for the finger slip but it is auto generated when adding to HA. when clicking on it it does show correct ook_sys_internal_temperature & fsk_sys_internal_temperature
I will keep an eye on the system and see what its like over the next few days and if anything goes missing again.
That is very strange, as the actual discovered property for this has
“SYS: Internal temperature”
in the code for this, and this is also how it is being discovered and displayed for my LilyGo.
Absolutely no “temo” in the code anywhere. Are you sure you didn’t rename these properties yourself and possibly slipped your finger?
Good to hear though that everything is working as expected with your two gateways now, and yes, sometimes HA needs a while to update and set to active all gateway properties after a HA restart - worst case a full 2 minutes until the next SYStoMQTT message is coming in to populate the gateway properties with. So best to wait at least 2 minutes after a HA restart before initiating new restarts.
I must appologise. 
. My Youngest Brat (an IT teacher at our local school) decided it would be fun to stomp thru my HA and rename EVER temp sensor to Temo. She done it in yaml so when I checked or added a name for the sensor in the UI it never changed. I have just sat and went thru all the sensors etc checking the yaml entries and found about 40 entries with name: xxxxxx Temo
“I could not see the woods for the trees” The last 48 hours has knocked me about too much.
I think I need to take a break from HA for a few days now that everything is working again…
p.s I promiss not to come back unless sommit drastic happens… 
