SONOFF Micro - 5V Wireless USB Smart Adaptor

Hardware
22

Much simpler than the one I made last year.

Prog adapter 1.27mm #2
Prog adapter 1.27mm #21600Ɨ900 186 KB

1 Like
23

@jschwerdlin & @gaz99

very advanced flashing utilities you got there :muscle:

Iā€™m always going the low-tech/low-effort way and just ask for one or two helping hands :open_hands:

For the sinilink device I actually just used dupont wires and holding them while flashing (3-4 hands were included in that action). :vulcan_salute:

Because ā€œfreeingā€ esp based device hardly takes 60 seconds (usually much less) I virtually never solder wires or pins but just do it always ā€œfreelyā€. Even shorting wires or loosing grip while flashing never killed any of my devices. Worst case is to initiate the flashing process once again - bricking espā€™s is simply not possible afaik. :ok_hand:

24

@lmatter I was hoping the same thing. Did you ever find and interface to use to type in wi-fi creds? I canā€™t get mine to fully connect

25

I did - check out my comment a bit after that one. I used my Windows laptop to create a ā€œhotspotā€ that only had 2.4GHz so I was able to get them registered with eWeLink. SONOFF Micro - 5V Wireless USB Smart Adaptor - #12 by lmatter

26

I wanted to keep them on the same lan so HA could use local API so didnā€™t want to go this route. Based on another thread I tried a tablet I had and my micros connected right away. Two different android phones didnā€™t work, but an android tablet worked perfect. Such a waste of time trying to get these things to connect!!!

27

Any chance you could share your yaml for these?

28

I think I got this from somewhere else, so I canā€™t take credit for this

Edit:
Looks like it came from here, but maybe has gotten updated since I first used it

substitutions:
  devicename: weatherwifiswitch
  upper_devicename: "Weather Wifi USB Relay"

esphome:
  name: $devicename
  platform: ESP8266
  board: esp01_1m


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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Weatherwifiswitch"
    password: "xxxxxxx"
    ap_timeout: 3min

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:



status_led:
  pin:
    number: GPIO16 # Blue LED

switch:
  # Relay
  - platform: gpio
    id: relay
    pin: GPIO5

  # Green LED
  - platform: gpio
    pin: GPIO14
    id: green_led
    inverted: true # start on

  # Switch template to link relay and green LED states
  # LED is on when relay is off
  - platform: template
    id: "${devicename}_relay"
    name: $upper_devicename
    lambda: |-
      if (id(relay).state) {
        return true;
      } else {
        return false;
      }
    turn_on_action:
        - switch.turn_on:
            id: green_led
        - switch.turn_on:
            id: relay
    turn_off_action:
        - switch.turn_off:
            id: green_led
        - switch.turn_off:
            id: relay

# Button
binary_sensor:
  - platform: gpio
    id: button
    pin:
      number: GPIO04
      mode: INPUT_PULLUP
      inverted: True
    on_press:
      - switch.toggle: "${devicename}_relay"
1 Like
29

Many thanks!

30

I wrote a short SINILINK guide a while ago.

1 Like
31

Was anyone able to get this to pass through data / does the sinilnk pass through or control the data lines?

32

To my knowledge the sinilink does pass data. Check the video on those devices by the guy with the Swiss accent.

2 Likes
33

I am anticipating a problem with access to Teslaā€™s API in the not too distant future which will knacker an automation I currently have for opening my electronic gate. I came across this device and then this thread and Iā€™m wondering whether perhaps this might provide an alternative for triggering my automation.

At the heart of my automation is a regular 1s ping from HA to the car. If it replies, that means the ignition has been switched on or the car has arrived home, and I open the gate. With a Tesla I canā€™t simply rely on the ping (the car can ā€œwake upā€ almost randomly and the crude approach would open the gate when I donā€™t want it open). After a ping, Iā€™ve added a check through the Tesla API for the carā€™s gear - if not in N (so R or D), then someone must be in the car and now I open the gate. However, I anticipate access to the Tesla API will be restricted or cost money in the not too distant future so Iā€™m looking for an alternative.

I wonder if I could use this device? Could I plug it into the carā€™s USB port and simply ping it? BUT! Unfortunately, I canā€™t simply rely on pinging something plugged into the Teslaā€™s USB ports as, once again, they too can come on randomly! As well as pinging it, can I have it normally switched off and press the switch on it when I get in the car to turn it on and so open the gate?

Hopefully this makes sense.

36

Sure, you could also throw a BLE beacon into your car and it will not be necessery anymore to ping it because it broadcasts itselfā€¦ :signal_strength:

If your car has an OBD(II) port, have a look into that because it gives real insides. So a ESP32 that actually knows what your car state is (R, D, ā€¦) and that works via local push with HA instead of pinging (:hammer:) is probably the go-to solution. :oncoming_automobile:

1 Like
37

Thanks. The OBD port sounds interesting. But to reiterate, anything that simply plugs into a USB port alone isnā€™t suitable because of the random wake ups.

PS Tesla uses BLE and Iā€™m using it but it doesnā€™t provide the gear state so at the moment itā€™s not quite a solution.

38

Anything against plugging into the OBD (On-board diagnostics) port then? You should get much more out of it than the gear state :wink:

39

I am aware what the OBD is and I even have something and an app for it. I did say that approach is interesting, I need to look in to how I might use it. Thanks again.

40

Anyway wrong thread / off topic. Feel free to open a thread if you want to go further so we donā€™t pollute this thread anymore :wink:

2 Likes