This is the forum archive of Homey. For more information about Homey, visit the Official Homey website.

The Homey Community has been moved to https://community.athom.com.

This forum is now read-only for archive purposes.

Sonoff / Ewelink switches

2

Comments

  • @robertklep: please Keep us updated about the Status of your App. I am keen to test it ...... Many thanks for your work!
  • robertkleprobertklep Member
    edited November 2017
    @Aaron yes, the device reports its status: it sends its current value when connecting to the (fake) cloud server, and also whenever the state is changed by pressing the button on the device.

    FWIW, my initial implementation can be found here: https://github.com/robertklep/name.klep.sonoff

    I've only tested this with an S20 device. I can't yet change the device state from Homey (this works now), but any changes that are made from the device itself (button press) are reported to the Homey driver.
  • Thanks. I will have a look at it on the Weekend.
  • @robertklep ; Great that you picked this up, thanks
    After downloading and unzipping the files, I could not find the file "pair.json"
    can you indicate, in what folder the file "pair.json" can be found or should be placed?
  • @JPe you need to create that file.
  • Cool, nice to know it reports back. For such a cheap device it is great that it does. Goin to order some, lets see what I can do with them.

    greeting,
    Aaron
  • @Aaron they're cheap, but I already managed to break at least one device  :s it worked for a couple of hours, now it's dead (the secondary of the mains-to-low-voltage transformer outputs 0V, I didn't measure the primary side because scary). I'm going to resolder all solder joints tomorrow, I've read that it happens quite often that there are bad ones.
  • @Aaron they're cheap, but I already managed to break at least one device  :s it worked for a couple of hours, now it's dead (the secondary of the mains-to-low-voltage transformer outputs 0V, I didn't measure the primary side because scary). I'm going to resolder all solder joints tomorrow, I've read that it happens quite often that there are bad ones.
    How come you're soldering them?
  • vaderag said:
    How come you're soldering them?
    Redoing the job that the manufacturer did. Some devices come with badly soldered parts that may cause faulty connections on the PCB, so taking a soldering iron and resoldering each joint may solve that problem.
  • vaderag said:
    How come you're soldering them?
    Redoing the job that the manufacturer did. Some devices come with badly soldered parts that may cause faulty connections on the PCB, so taking a soldering iron and resoldering each joint may solve that problem.
    Oh, I see. I've never had any issues, so far so good!
  • I just published a beta release: https://apps.athom.com/app/name.klep.sonoff

    I only have two types of devices (S20 and a Basic), hopefully it'll work for other types of devices too. The driver doesn't (yet) support sensors (mainly because my devices don't have any :smile:).
  • Amazing!

    Away at a wedding this weekend but will absolutely check that out next week :)

    I have a sensor device but don't actually use the sensor, so will be interesting to see if it works with that
  • @robertklep, great idea from the app! Just tried it, unfortunately it didn't work (yet). Tried it on the Sonoff RF module. Did a factory reset, was able to connect to connect to the ITEAD-10000xxx Wifi and got an IP-address: 10.10.70.2 and was able to ping 10.10.7.1. 
    Got the following message in curl: "curl: (56) Recv failure: Connection was reset". Tried it multiple times. Wil look if I can find some time this weekend to do some more testing.

    btw, there is a small type in your Readme. In my curl version there has to be no space between "content-type:" and "application", otherwise it wanted to do a DNS lookup for "application".
  • robertkleprobertklep Member
    edited December 2017
    @caros next time, try and see if this returns anything: curl http://10.10.7.1/device

    If that doesn't work: according to this blogpost (https://blog.ipsumdomus.com/sonoff-switch-complete-hack-without-firmware-upgrade-1b2d6632c01), you may need to set an explicit route (I didn't have to do this on macOS, but perhaps it's required on other OS'es):

        route change 0.0.0.0 mask 0.0.0.0 10.10.7.1

    Also, if you need to remove the space, perhaps you need to use double quotes (") instead of single quotes (') that I used in the README.
  • Still no luck yet. Route change not necessary, since there is an IP connection. I can also see this with netstat:

    >netstat -ano | findstr 10.10.7.1
      TCP    10.10.7.2:35116        10.10.7.1:80           ESTABLISHED     12484

    Curl to device page, gives me nicely the espected results:
    {
    "deviceid":"10000xxxx",
    "apikey":"xxxx-xxxx-xxxxx-xxx-xxx",
    "accept":"post"
    }

    No luck with other quotes either. Will try it some other time again.

  • robertkleprobertklep Member
    edited December 2017
    Caros said:
    Still no luck yet. Route change not necessary, since there is an IP connection. I can also see this with netstat:

    >netstat -ano | findstr 10.10.7.1
      TCP    10.10.7.2:35116        10.10.7.1:80           ESTABLISHED     12484

    Curl to device page, gives me nicely the espected results:
    {
    "deviceid":"10000xxxx",
    "apikey":"xxxx-xxxx-xxxxx-xxx-xxx",
    "accept":"post"
    }

    No luck with other quotes either. Will try it some other time again.

    Let me know if you can get it working, and on what OS you are, I'd be happy to include instructions for other OS'es than the one I'm using :smiley:

    @caros I just realized that this may actually be caused by not including a space in the header. I just checked, and curl will send an invalid header line in that case, which may be why you're getting the Connection was reset error. So the space needs to be there.

    Or, you could try leaving out the header entirely:
    curl --data-binary @pair.json -XPOST http://10.10.7.1/ap


  • @robertklep, thanks for all your quick responses. Today I tried it with the 'old' Sonoff RF and a brand new 'regular' Sonoff. I can't get the POST message override the values on both of the Sonoffs. I get timeouts, while the curl for device info gives me the answer in a second. This is wat I've tried:
    - Curl under Windows
    - Installed Kali within Hyper-V, installed curl on it (so I could use single quoted with space)
    - Used two types of Sonoff's
    - Used all the possible quotes and even withouth headers

    All of this, didn't gave me the right results. I've added a Wireshark capture, where you can see that the Sonoff doesn't response after the initial acknowledgement (I've removed my private information offcourse). First one is the TCP stream in packets, second one is the TCP stream in total. Then after a while the WLAN of the Sonoff disappears and that's the moment when the timeout occurs, which sounds logical to me :).


  • @caros I assume that the IP-address passed in "serverName" is correct? Also, are you running the Sonoff app on Homey? If not, make sure it does.
  • @robertklep, yes everything was fine. This did the trick for me. Wireshark sniffing helped me :)

    curl --data-ascii @pair.json -XPOST -H "content-type: application/json" http://10.10.7.1/ap

    I was thinking why it should be binary, when it is ASCII text.
  • Caros said:
    @robertklep, yes everything was fine. This did the trick for me. Wireshark sniffing helped me :)

    curl --data-ascii @pair.json -XPOST -H "content-type: application/json" http://10.10.7.1/ap

    I was thinking why it should be binary, when it is ASCII text.
    Using `--data-binary` should prevent curl from modifying the data in any way. I'm not sure why it doesn't work for you, but glad it's solved! I will update the documentation.
  • Thanks for the quick responses! Can also confirm that it's working for the Sonoff RF

  • Caros said:
    Thanks for the quick responses! Can also confirm that it's working for the Sonoff RF

    Great! So when you switch the device over 433Mhz, Homey is notified properly?
  • CarosCaros Member
    edited December 2017
    Yes, just tested. It's great. Whether I press the physical button or the RF button, within a second Homey changes the state. Well made!
  • Caros said:
    Yes, just tested. It's great. Whether I press the physical button or the RF button, within a second Homey changes the state. Wel made!
    Awesome, thanks! I'll add it to the list of supported devices :smiley:
  • @robertklep
    I have a question - if i set up a Sonoff with your homey app, do I lose the ability to control via the ewelink app from that point, or can they be used in tandem? 
  • robertkleprobertklep Member
    edited December 2017
    vaderag said:
    @robertklep
    I have a question - if i set up a Sonoff with your homey app, do I lose the ability to control via the ewelink app from that point, or can they be used in tandem? 
    Sorry, they can't be used in tandem :/

    If you happen to use iOS: I use the HomeyKit app to control my devices, including the Sonoff's, which works very well.
  • CarosCaros Member
    edited December 2017
    @robertklep, It's not working stable for me. Once paired I'm able to control the Sonoff, but after a while not anymore. Rebooting the Sonoff solves the issue for a while, but it's not stable :( At the moment I can ping the Sonoff (gave it a static IP), but can't control it from my Homey.
  • @caros how long is "after a while"?
  • robertkleprobertklep Member
    edited December 2017
    Question for all users that have installed my app:

    I'd like to be able to add the ability to determine which type of Sonoff device you are pairing with Homey. For this, I'd like to gather some information about your devices.

    When you pair a device with Homey, it's given a rather cryptic name, consisting of "$MODEL_NAME@$DEVICE_ID (ROM $ROMVERSION)".

    If you're interested in helping me out, can you post (through a direct message, or on Slack; I'm not sure how privacy sensitive the device id is, so please don't use a public forum to post it):
    • the "commercial" name of the device ("S20", "Sonoff Basic", "TH10", ...)
    • the cryptic name that the driver initially gives
    Hopefully, with more information the driver can better differentiate between devices and show the proper icon for each different type.
  • @robertklep
    I'll be happy to help but can you advise when the stable version will be pushed? After issues installing beta apps and having to redo all my flows I'm reluctant to install beta apps...
Sign In or Register to comment.