Finally got a working board following breadboard prototype

[mikekay1]

The remote is now working while plugged in but need help with yaml and gpio mapping? Do I need to put this into the yaml or should this work out the box with esphome v2.0 software?

Thank guys!

[mikekay1]

Some more info on this, im so close I can taste it.

When tx and rx are correct per schematic I get collision detected which floods the logs... See first three pictures.

When I reverse the TX and RX problem goes away but no status is given and nothing works.

Last picture shows my wiring to GDO

Should I be flashing v2.0 esphome or v2.5 esphome?

Any help would be appreciated!

[Kaldek]

Flash v2.5 and then do the YAML edit is what I would recommend.

If you can't work out to upload a fully custom YAML to the board, I would use the default pins for now to get functioanlity, and then pivot to custom pins later. This means, for now, just using this YAML file: from https://github.com/ratgdo/esphome-ratgdo/blob/main/static/v25board_esp32_d1_mini.yaml

Choosing which YAML file to use means you have to have ESPHome Add-On installed and you have to "Adopt" the ratgdo into ESPHome then click the Edit button which lets you alter the device's configuration and which YAML file to source.

[mikekay1]

Hey man, thanks for the quick response. Default being

Tx:gpio16 (Red) Rx:gpio21 (White) Obstruction:23 (Black)

Are you saying using the default without switching thr boardtype or gpio (leaving it as d4)?

[mikekay1]

I will to a massive commit about how to get this running once I get this working, I work professionally in the field IT and electronics and somehow failing the basics. going to continuity test the mosfets and make sure none of them are shorted open. Im almost postitive I have everything right, and now my questions are just seeming to be almost dumb because I dont know where the disconnect is.

[mikekay1]

Flash v2.5 and then do the YAML edit is what I would recommend.

If you can't work out to upload a fully custom YAML to the board, I would use the default pins for now to get functioanlity, and then pivot to custom pins later. This means, for now, just using this YAML file: from https://github.com/ratgdo/esphome-ratgdo/blob/main/static/v25board_esp32_d1_mini.yaml

Choosing which YAML file to use means you have to have ESPHome Add-On installed and you have to "Adopt" the ratgdo into ESPHome then click the Edit button which lets you alter the device's configuration and which YAML file to source.

If running v2.5 are we still following the wiring diagram of 2.0? we only have one obstruction wire. Also my garage door is security 2.0+ so I dont mind the v2 firmware. Ill post back once I check the mosfets

[sanjay900]

Flash v2.5 and then do the YAML edit is what I would recommend. If you can't work out to upload a fully custom YAML to the board, I would use the default pins for now to get functioanlity, and then pivot to custom pins later. This means, for now, just using this YAML file: from https://github.com/ratgdo/esphome-ratgdo/blob/main/static/v25board_esp32_d1_mini.yaml Choosing which YAML file to use means you have to have ESPHome Add-On installed and you have to "Adopt" the ratgdo into ESPHome then click the Edit button which lets you alter the device's configuration and which YAML file to source.

If running v2.5 are we still following the wiring diagram of 2.0? we only have one obstruction wire. Also my garage door is security 2.0+ so I dont mind the v2 firmware. Ill post back once I check the mosfets

With ESPHome, there is no difference between v2.5 and v2.0 besides that one pin change, so if your following the schematic you can just flash 2.0

[mikekay1]

Thanks @sanjay900, upgrading is as easy as changing the yaml and then redeploying the yaml correct? Im not sure which version I am on. I used the esphome web installer and flashed 2.0, after I changed the pinouts and made edit to package for v25 firmware. We are still using the wiring of v2.0 board correct red to red, black to obstruction sensor, and white to other side of obstruction sensor.

Continuity on mosfets is fine :(

[sanjay900]

Thanks @sanjay900, upgrading is as easy as changing the yaml and then redeploying the yaml correct? Im not sure which version I am on. I used the esphome web installer and flashed 2.0, after I changed the pinouts and made edit to package for v25 firmware. We are still using the wiring of v2.0 board correct red to red, black to obstruction sensor, and white to other side of obstruction sensor.

Continuity on mosfets is fine :(

Yeah, that sounds right for the pins to use. Could you get a clearer photo of your breadboard, just want to confirm the wiring.

[sanjay900]

If it helps, here's a photo of my working breadboard

[mikekay1]

Its not my camera that is blury its the same lettering on these knock off esp32's. So v25 uses pin gpio16 correct. And with the wall panel button, the white cable goes directly into GDO.

Cant post picture on mobile one sec let me hop on the computer

[mikekay1]

@sanjay900 , pretty sure the circuit is good but heres another picture let me know if you see anything weird.

[sanjay900]

So v25 uses pin gpio16 correct. And with the wall panel button, the white cable goes directly into GDO.

Ah, other way around, v20 uses GPIO16, v25 uses GPIO22

[mikekay1]

So v25 uses pin gpio16 correct. And with the wall panel button, the white cable goes directly into GDO.

Ah, other way around, v20 uses GPIO16, v25 uses GPIO22

So you are running v20 right, cant really see the resistor divider at d23 but pretty sure our ciruits are the exact same.

[Kaldek]

So v25 uses pin gpio16 correct. And with the wall panel button, the white cable goes directly into GDO.

Ah, other way around, v20 uses GPIO16, v25 uses GPIO22

So you are running v20 right, cant really see the resistor divider at d23 but pretty sure our ciruits are the exact same.

I forgot that for ESP32 we started recommending using v2.0 YAML settings due to all the pin mapping "fun" that the other folks went through.

https://github.com/Kaldek/rat-ratgdo/blob/main/Supported%20Boards.md#esp-32-based-boards

[mikekay1]

@Kaldek thanks for chiming in mate, everything with the board is 1:1 to your working prototype. Im wondering if wiring to GDO is incorrect? I know the black wire at GDO side in picture leads to "R" terminal on wall panel.

[sanjay900]

So v25 uses pin gpio16 correct. And with the wall panel button, the white cable goes directly into GDO.

Ah, other way around, v20 uses GPIO16, v25 uses GPIO22

So you are running v20 right, cant really see the resistor divider at d23 but pretty sure our ciruits are the exact same.

Correct, i am using v20. I also looked at your breadboard and it all seemed the same.

[Kaldek]

@Kaldek thanks for chiming in mate, everything with the board is 1:1 to your working prototype. Im wondering if wiring to GDO is incorrect? I know the black wire at GDO side in picture leads to "R" terminal on wall panel.

Does this help?

[Kaldek]

Umm @mikekay1 why is your Wroom32 GND pin not connected to GND?

[sanjay900]

oh wow that would do it haha

[Kaldek]

Yeah ya know...

[mikekay1]

Umm @mikekay1 why is your Wroom32 GND pin not connected to GND?

Oh but it is at the top left of breadboard then jumped back to other side of the breadboard rail.

[sanjay900]

Umm @mikekay1 why is your Wroom32 GND pin not connected to GND?

Oh but it is at the top left of breadboard then junped back to other side of the breadboard rail.

Ah yeah I see it now, it was hidden behind one of the other wires It doesn't actually look connected in either of the images cause it's hidden by the obstruction wire

[mikekay1]

All good these are a pain in the ass to photograph. I have 4 terminals on GDO. Red T1, White T2, White/Grey T3, and Black T4. Red to Red, Black to Black does esp32 white wire connect to T2 or T3. Which is ground? That might be my problem...

[Kaldek]

Umm @mikekay1 why is your Wroom32 GND pin not connected to GND?

Oh but it is at the top left of breadboard then jumped back to other side of the breadboard rail.

Weird, the pinouts I found for the WROOM 32 don't have that GND pin on them, hence why I didn't look up there.

[sanjay900]

Yeah, that esp32 pinout was different to mine and that threw me off as well

[mikekay1]

Maybe its mislabeled! I could try another ground while you confirm the terminal question above.

[Kaldek]

All good these are a pain in the ass to photograph. I have 4 terminals on GDO. Red T1, White T2, White/Grey T3, and Black T4. Red to Red, Black to Black does esp32 white wire connect to T2 or T3. Which is ground? That might be my problem...

I believe both of those are GND. One is the GND for the wall controller and the other is the GND for the obstruction sensors. I would use T2 for GND though.

You might also be at the "bust out the oscilloscope" stage if you can't get beyond this. You should NOT be getting the "Collision Detected" messages.

[mikekay1]

Yea right eh? This is driving me nuts. Thanks for the help by the way. I couldnt have done it on my own.

My board is this one, not sure if that helps at all. https://esphome.io/devices/nodemcu_esp32.html

Maybe the fact that the T3 GND is acting as different circuit is messing it all up. Let me try and swap that over. Also the ground on the breadboard. GND should be shared on 3.3v rails and 5v rails... But incase it isnt.

Let me post back in a little bit

[sanjay900]

What you also could try is just wiring up only the RX transistor and its resistor and just the red wire and ground, and seeing if you still get that collision detected message. If you do, then it might be worth trying another transistor or something, since it really shouldn't be doing that.

[mikekay1]

its not even letting me use substitutions. I am going to swap both of the 2n7000's

Install ratgdov2-e8facc.yaml
INFO ESPHome 2023.10.5
INFO Reading configuration /config/esphome/ratgdov2-e8facc.yaml...
ERROR Error while reading config: Invalid YAML syntax:

Duplicate key "substitutions"
  in "/config/esphome/ratgdov2-e8facc.yaml", line 13, column 1:
    substitutions:
    ^
NOTE: Previous declaration here:
  in "/config/esphome/ratgdov2-e8facc.yaml", line 1, column 1:
    substitutions:
    ^

substitutions:
  id_prefix: ratgdov2
  friendly_name: "RATGDOv2"
  uart_tx_pin: GPIO16
  uart_rx_pin: GPIO21
  input_obst_pin: GPIO23
  status_door_pin: GPIO22
  status_obstruction_pin: GPIO18
  dry_contact_open_pin: GPIO12
  dry_contact_close_pin: GPIO14
  dry_contact_light_pin: GPIO10

web_server:

esphome:
  name: ${id_prefix}
  friendly_name: ${friendly_name}
  name_add_mac_suffix: true
  project:
    name: ratgdo.esphome
    version: "2.0"

esp32:
  board: nodemcu-32s

dashboard_import:
  package_import_url: github://ratgdo/esphome-ratgdo/v2board_esp32_d1_mini.yaml@main

packages:
  remote_package:
    url: https://github.com/ratgdo/esphome-ratgdo
    files: [base.yaml]
    refresh: 1s

# Sync time with Home Assistant.
time:
  - platform: homeassistant
    id: homeassistant_time

ota:

improv_serial:

api:
  encryption:
    key: 

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

logger:

#packages:
#  ratgdo.esphome: github://ratgdo/esphome-ratgdo/v20board_esp32_d1_mini.yaml@main
#

#substitutions:
#  id_prefix: ratgdov25
#  name: ratgdov2-e8facc
#  friendly_name: RATGDOv2
#  uart_tx_pin: GPIO16
#  uart_rx_pin: GPIO21
#  input_obst_pin: GPIO23
  #status_door_pin: GPIO5
  #status_obstruction_pin: GPIO12

#esphome:
#  name: ${name}
#  name_add_mac_suffix: false
#  friendly_name: ${friendly_name}

But my yaml should be fine? maybe its because I declared my board type, I am ready to just buy a bloody wemos d1 mini........

[sanjay900]

Have you tried just straight up deleting your current board from esphome, and then flashing 2.0 again from scratch using the web flasher?

[mikekay1]

Have you tried just straight up deleting your current board from esphome, and then flashing 2.0 again from scratch using the web flasher?

You know what this isn't a bad idea, going to try this as well.

[mikekay1]

Have you tried just straight up deleting your current board from esphome, and then flashing 2.0 again from scratch using the web flasher?

Collisions are detected even when there was nothing attached, fresh flash. Is there a need to customize the YAML after flashing or does the schematic take into account the GPIO 'translations' automagically?

You will get collisions listed if the Red wire is not connected. The red wire must be connected for the Collisions Detected message to go away.

If you connect it and still have "Collision Detected" then you're not seeing the +12v on the red wire, or the RX MOSFET is not switching, or you have the wrong GPIO pins set for RX.

[mikekay1]

you think something about the board makes it incompatible because it boots that pin low? At this point I'm now ready to buy a d1 mini... I could have bought 20 of these damns boards if I had instead worked a second job lol. I'm guessing I would have to customize my own YAML at this point and try and find which pin is high at boot, and alter it...

[Kaldek]

you think something about the board makes it incompatible because it boots that pin low? At this point I'm now ready to buy a d1 mini... I could have bought 20 of these damns boards if I had instead worked a second job lol. I'm guessing I would have to customize my own YAML at this point and try and find which pin is high at boot, and alter it...

It's not about which pins are high at boot, it's about which pins that the code is setting to use as TX and RX, followed by whether the wiring at the circuit level (e.g., the MOSFETs) is wired incorrectly.

[sanjay900]

you think something about the board makes it incompatible because it boots that pin low? At this point I'm now ready to buy a d1 mini... I could have bought 20 of these damns boards if I had instead worked a second job lol. I'm guessing I would have to customize my own YAML at this point and try and find which pin is high at boot, and alter it...

It's not about which pins are high at boot, it's about which pins that the code is setting to use as TX and RX, followed by whether the wiring at the circuit level (e.g., the MOSFETs) is wired incorrectly.

It's Friday afternoon here and my brain is heading into IDGAF mode but let me try to explain the logic.

Ill admit i had trouble with this too for a while, but i wrapped my head around it eventually. The serial pin is always held at 12v until either device wants to signal, so the ESP32 assumes if the RX pin is low, that something is trying to write, hence, collision

It means that for some reason either your serial pin is not at 12v, or your wiring is incorrect and that 12v signal isnt reaching pulling the RX pin high via the mosfet, due to a bad mosfet or incorrect wiring. Hence why my first thought was to get rid of everything and only hook up the RX portion of the schematic, and see if that on its own works.

[Kaldek]

Everyone needs to ignore what I'm saying at the moment as my brain has just decided to stop functioning for the week and I'm saying gibberish which is probably backwards.

I've written some stupid stuff over the last 20 minutes.

Fundamentally, if nobody is transmitting, the Red wire is at +12v. The circuit design and the logic for TX and RX is based on that. What the behaviour is at the TX and RX pins of the ESP is based on the circuit design of the MOSFET circuits.

[mikekay1]

Have a good Friday lads, we are at almost midnight on Thursday here in GMT-4. Regardless, I will try to connect red wire and see if the messages go away. Unless I got a big batch of failed 2n7000s i cant picture anything else being wrong. Was really hoping the T2 to GND would have fixed it but nope. Now truly wonderin if the breadboard would get the same problems if wired to a wemos d1 mini...

[sanjay900]

Have a good Friday lads, we are at almost midnight on Thursday here in GMT-4. Regardless, I will try to connect red wire and see if the messages go away. Unless I got a big batch of failed 2n7000s i cant picture anything else being wrong. Was really hoping the T2 to GND would have fixed it but nope. Now truly wonderin if the breadboard would get the same problems if wired to a wemos d1 mini...

Haha I'm sitting here in GMT+13, I don't think your problem is specifically the esp32, but I'm also unsure what the problem actually is.

[mikekay1]

you think something about the board makes it incompatible because it boots that pin low? At this point I'm now ready to buy a d1 mini... I could have bought 20 of these damns boards if I had instead worked a second job lol. I'm guessing I would have to customize my own YAML at this point and try and find which pin is high at boot, and alter it...

It's not about which pins are high at boot, it's about which pins that the code is setting to use as TX and RX, followed by whether the wiring at the circuit level (e.g., the MOSFETs) is wired incorrectly. It's Friday afternoon here and my brain is heading into IDGAF mode but let me try to explain the logic.

Ill admit i had trouble with this too for a while, but i wrapped my head around it eventually. The serial pin is always held at 12v until either device wants to signal, so the ESP32 assumes if the RX pin is low, that something is trying to write, hence, collision

It means that for some reason either your serial pin is not at 12v, or your wiring is incorrect and that 12v signal isnt reaching pulling the RX pin high via the mosfet, due to a bad mosfet or incorrect wiring. Hence why my first thought was to get rid of everything and only hook up the RX portion of the schematic, and see if that on its own works.

This seems like a good idea, RX by color coding is white. So just the white white with no Red attached

Or

White and red attached to GDO?

Will test tomorrow a bit tired of this myq drama.

Thanks all for all the help!!

[mikekay1]

tried changing the pins, tried everything even with changing the pins something is just not working right, ordered a weemos if its not that its a bad 2n7000 batch which will all be getting send back. Anyone have a amazon canada link to the right ones I feel like I may have bought something different?

In conclusion I am a complete idiot. As I go to post the link I find out these are LM35/LM35DZ in a TO-92 package :'( link

what a gremlin... guys I've been using a bloody temperature sensor the entire time... after this ticket is closed can we delete it for ever and pretend none of this ever happened?

new parts on order... I figured there was something very very wrong. I've designed a ton of these circuits before. will keep everyone posted!

[Kaldek]

All good mate, we've all been there!!!!

[mikekay1]

Still not working able to close and open door, but not get status, or trigger light on/off. Going to buy a weemos and post back

[mikekay1]

Bought a weemos, reflashed it and rebuild everything what else can I do... I am at my whits end with this thing.

Any help, should I solder everything