I saw on the discord channel they got you set up to enable the GIOP pins as a UART. So I assume you’re good. But if you do want to remove ttyAML0 you edit the line I mentioned. You will see it actually has three console values being set. Leave the one I didn’t mention and remove “console=ttyAML0,115200n8 console=both”. I’m pretty sure that will do it for you after a reboot. You could then use something like the stty command to display or set the serial port parameters if need be as discussed here.
On the discord channel we “maybe” enabled UART_EE_A, so in the device list I can see a ttyAML0 and ttyAML1. But ttyAML1 isn’t accepted by the software, because I think isn’t correctly defined as serial port. Maybe I must insert any definition of AML1 into extlinux.conf. But not sure what’s correct definition. Second strange thing is, that on the link which you sent in the last post is always ttyS0 or ttyS1, but this I don’t have.
The device name is determine by the hardware and then associated driver. The fact that it is ttyAML vs ttyS shouldn’t matter. That would seem to be a problem with the software you are using. If the software expects it to be named ttyS0 you could try make a hard link using
ln /dev/ttyAML0 /dev/ttyS0
This then give you a device named /dev/ttyS0 that is really just /dev/AML0
Alternatively you could link /dev/ttyS0 name to the other serial device you enabled with the overlay.
so I opened a extlinux.conf :
label default
kernel ../Image
initrd ../uInitrd
fdtdir ../amlogic/
fdt ../amlogic/meson-g12b-odroid-n2-plus.dtb
fdtoverlays ../amlogic/overlays/meson-g12b-odroid-n2-uart0.dtbo
append earlyprintk console=tty1 console=ttyAML0,115200n8 console=both rw root=PARTUUID=0407e572-01 rootwait rootfstype=ext4 fsck.repair=yes loglevel=1 net.ifnames=0 no_console_suspend clk_ignore_unused usb-storage.quirks=0x152d:0x0576:u init=/sbin/init
but rename to ttyS1 also doesn’t work :
HANDLER_CONFIGURATION_PENDING
{serialPort=The value of /dev/ttyS1 does not match the enabled options parameter. Allowed options are: [ParameterOption [value="/dev/ttyUSB1", label="/dev/ttyUSB1"], ParameterOption [value="/dev/ttyUSB0", label="/dev/ttyUSB0"], ParameterOption [value ="/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0", label="/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0"], ParameterOption [value="/dev/ serial/by-id/usb-1a86_USB2.0-Ser_-if00-port0", label="/dev/serial/by-id/usb-1a86_USB2.0-Ser_-if00-port0"]]}
question is, if inside extlinux.conf this ttyAML1 or ttyS1 must be configurated as serial port
Looks like it’s telling you it wants a USB serial device. You could try the ln command again but this time ln /dev/ttyUSB0 ti the AML device instead of ttyS0 and see if that works. If it doesn’t work then remove the ln created for USB0. You could also just get a USB serial port device like this one and see if that meets your needs.
I already have two USB devices 
ttyUSB0 and ttyUSB1. So he wants this two and next serial device AML1 looks like doesn’t exist for him.
does
sudo dmesg |grep tty
show your AML devices as serial devices. On my system I get these lines in the output showing serial devices
[ 0.504726] ff803000.serial: ttyAML0 at MMIO 0xff803000 (irq = 14, base_baud = 1500000) is a meson_uart
[ 0.506430] ffd24000.serial: ttyAML1 at MMIO 0xffd24000 (irq = 15, base_baud = 1500000) is a meson_uart
Assuming you get something simular, I don’t know why your software isn’t providing these as options for possible assignment. You should reach out to that community and ask them what is required to get a serial device to be available. Provide them with the dmesg output and see what insight they can provide. It may be that software only supports usb devices and not on board devices.
You might also want to switch over to HA for your home automation needs.
It shows that both ttyAML0 and ttyAML1 are serial devices, so I would question why they don’t work with the software you’re trying to use.
I agree, I already sent a question. We will see.
I’ve integrated my brother’s old home wiring into esphome with a MCP23017 IO extender. It gives you 16 contacts from which you can build binary sensors in Home Assistant with. It’s pretty simple stuff.
@pashdown I’m working on the same setup; any suggestions on how to manage a sensor like that one?
Essential the contact change the status and return to the original on extension of the cord (or in the other way round) , so the binary sensor change many time in a short timeframe
That looks interesting. Any chance you can provide a little documentation on the ESP you used, how you wired it and then the code you’re running?
It was a simple 8266. Not a lot of processing going on, so it works fine. Here is my esphome setup:
substitutions:
device_name: "doors"
friendly_name: "Doors"
esphome:
name: ${device_name}
esp8266:
board: d1_mini
wifi:
networks:
- ssid: !secret wifi_ssid
password: !secret wifi_password
# Optional manual IP
manual_ip:
static_ip: 192.168.0.7
gateway: 192.168.0.1
subnet: 255.255.255.0
# use_address: 192.168.1.190
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap: {}
# Enable logging
logger:
# Enable Home Assistant API
ota:
password: !secret ota_password
api:
encryption:
key: "ENCRYPTIONKEYHERE="
captive_portal:
status_led:
pin: GPIO2
i2c:
sda: D6
scl: D5
scan: True
# Example configuration entry
mcp23017:
- id: 'mcp23017_hub'
address: 0x20
# Individual inputs
binary_sensor:
- platform: gpio
device_class: door
name: "Guest Exit"
pin:
mcp23xxx: mcp23017_hub
# Use pin B7
number: 15
# One of INPUT or INPUT_PULLUP
mode:
input: true
pullup: true
inverted: false
- platform: gpio
device_class: door
name: "Lower Rear Middle Door"
pin:
mcp23xxx: mcp23017_hub
# Use pin B6
number: 14
# One of INPUT or INPUT_PULLUP
mode:
input: true
pullup: true
inverted: false
- platform: gpio
device_class: door
name: "Kitchen Door"
pin:
mcp23xxx: mcp23017_hub
# Use pin B5
number: 13
# One of INPUT or INPUT_PULLUP
mode:
input: true
pullup: true
inverted: false
- platform: gpio
device_class: door
name: "Bunker Exterior"
pin:
mcp23xxx: mcp23017_hub
# Use pin B4
number: 12
# One of INPUT or INPUT_PULLUP
mode:
input: true
pullup: true
inverted: false
- platform: gpio
device_class: door
name: "Bunker Interior"
pin:
mcp23xxx: mcp23017_hub
# Use pin B3
number: 11
# One of INPUT or INPUT_PULLUP
mode:
input: true
pullup: true
inverted: false
- platform: gpio
device_class: door
name: "Guest Interior"
pin:
mcp23xxx: mcp23017_hub
# Use pin B2
number: 10
# One of INPUT or INPUT_PULLUP
mode:
input: true
pullup: true
inverted: false
- platform: gpio
device_class: door
name: "Deck Door"
pin:
mcp23xxx: mcp23017_hub
# Use pin B1
number: 9
# One of INPUT or INPUT_PULLUP
mode:
input: true
pullup: true
inverted: false
- platform: gpio
device_class: door
name: "Garage Man Door"
pin:
mcp23xxx: mcp23017_hub
# Use pin B8
number: 8
# One of INPUT or INPUT_PULLUP
mode:
input: true
pullup: true
inverted: false
- platform: gpio
device_class: door
name: "Front Door"
pin:
mcp23xxx: mcp23017_hub
# Use pin A1
number: 1
# One of INPUT or INPUT_PULLUP
mode:
input: true
pullup: true
inverted: falseI’m guessing if it is two wire, one wire to the ground of the ESP and the other wire to a GPIO pin.
Thanks for adding the update.
yes, correct. any ideas regarding how to count the events?