Itead Sonoff might be good to consider

WebThings
#10

It is misunderstanding I guess.

I would separate two things:

  1. Sonoff with OEM FW (out of the box)
  • is controlled solely via remote cloud through eWeLink app ( either Android or iPhone), furthermore is compatible with Alexa, Nest, FTTT but there is no direct access/control from PC possible.
  • Internet access is required to control it (yeah, there is a hardware button as an option).
  1. Sonoff with custom FW (for example Tasmota, but there are more)
  • is accessible directly (via IP) from any device able to browse web
  • controlled via MQTT
  • compatible with Domoticz
  • compatible with almost any other home automation SW
  • compatible with dozens sensors
  • it can work within WIFI LAN, internet access is not needed
  • it is highly customizable (from both HW and FW side)
  • R Pi is one of compatible means only :wink:

There are a few cons or challenges rather to say :

  • user have to flash custom FW ( several ways how to do it exist)
  • lost guarantee of cheap, but reliable device (based on my experience)

Based on above, I believe that Sonoff deserved to be included :slight_smile:

#11

Indeed, for those who aren’t familiar with the device you will need to solder on some headers and use a separate FTDI programmer to connect USB to serial input. Once that is done, writing some code to interact with the relay and indicators is fairly straightforward. However, for the more feature-rich products from Itead coding is going to be less straightforward. They do have a product that monitors energy usage (i.e. kWh) but creating custom firmware to make it a Web Thing is obviously going to be more involved. One interesting feature of the Sonoff is being able to pair it with a key-fob (an accessory from Itead). If you can get your firmware to talk via RF you then have a way of doing things like setting the WiFi SSID and password.

Once that’s done, share your code and we’ll all benefit. :grinning:

#12

I think we should go directly to itead and ask them to enable Sonoff devices to act as native web of things compatible devices. Ping me if you have an inside connection. In general it should be easier and cheaper (requires less up front as well as ongoing resources) if ODMs produce and maintain devices that simply advertise themselves as web things. As users, we don’t want to see devices automatically hooked up to cloud services. We might want to run them in an environment without Internet access. Especially bad are devices that are connected to the cloud via proprietary silo’s with no exposed APIs. :frowning:

#13

Hey Kathy,

After writing my last post, I came to the same conclusion. That’s what standards are for right?

#14

I have to admit my surprise that the Sonoff dual and basic are not supported. An extremely common use case is to use these modules with TASMOTA firmware.

To flash the firmware no soldering is required… in fact, most versions can be flashed wirelessly.

I will see if I can find a way to get them working when I have my dongle.

#15

If I have the time this weekend, I’ll publish a platform-io project to control the classic sonoff switch through the GateWay.
Don’t expect a fancy UI like Tasmota or ESPurna…

#16

I would be happy to give it a try. Would your example reflash the sonoff device to turn it into a native web thing? or go through some other gateway addon? Ideally Sonoff and other commercial Wi-Fi (or wired) devices that support IP comms would be sold with native web thing support.

For this test I don’t care if I need to hard code a Wi-Fi ssid and password into the Sonoff device firmware.

Ultimately though, for commercial devices, it would be nice to have a universally recognized and broadcast ssid/password that all native web things default to looking for when they are unprovisioned. (The ubiquitous “provisioning channel” would be isolated and all network traffic dead-ended to the AP that is broadcasting it.) The temp connection would be enough for users to “find” new IoT/WoT devices and authorize them (or not) to obtain secure/private network credentials.

1 Like
#17

The first iteration will be just that, bare bones flashable firmware with hard coded settings. Only for the enthusiastic and the community.

#18

Kathy @ kgiori majority of Sonoff devices is possible to flash with a custon FW using original OTA mechanism.
After flash it acts as a native web thing, with own web API, no further gateway is needed.
You can access them within closed intranet (home wifi, etc) without access to the NET.
It offers (after flash) complete independence on OEM cloud/gateway, broader portfolio of sensors etc.

#19

I have S26 with stock fw … tell me if there is anyone interest into connecting it.

#20

Any luck building a PlatformIO project to reflash a Sonoff smart plug as a web thing? Given a working solution, it will be easier for itead to learn how to support the native web thing API out of the box, for all their IoT products. No need for something fancy, just a technical implementation that works. And in the meantime it would let those of us with existing units turn them into native web things too.

#21

There are various projects to provide alt fw for ESP8266 based products, I guess they should be adapted to support PlatformIO, any preferences ?

#22

One question is whether or not there is a way to re-image a Sonoff smart plug without breaking open the plastic molding. Even better however would be to find an engineer who works for itead to implement native web thing support in the product directly. Mozilla would happily provide her (or him) with a web thing API implementation for Sonoff smart plugs, in any language. Knock, knock, anyone home at iTead?

#23

If anyone is still interested, here’s the repo for the Sonoff Basic WebThing native implementation :smiley:

This repo is intended to be a tech demo, and not a full solution like Tasmota / ESPUrna / ESPEasy / …
If you wan’t that kind of functionality, I’d recommend asking them to implement the API.

#24

Thanks, I was about to do it, but you were faster at reimplementing it. (btw the LED example is similar isnt it ? ssid is still hardcoded) .

The other approch would be to patch Tasmota to use webthing API.

At worst case if Tasmota does not want to use WT API, we can still bridge to current REST API or MQTT (to use vanilla Tasmota).

Any opinion to push this further ?

#25

The library was in the works for some time, but never gotten around to it, and yes it’s very similar to the LEDLamp example. Sometimes people only need a familiar situation to get the gears working :wink:

Both Tasmota & ESPUrna are very modular in their structure, it’s a pleasure to look at and with so many compiling options I would believe that there can be a place for the WT API to be implemented.
The question are: Will the implementation cause any bugs? How can the WT API modularized to fit all use cases?
Also the WT API -in my opinion- is mature enough to handle what the Sonoffs can throw at it, but this may be a concern of the developers.

#26

Is anyone interested to upstream this in:

I can mentor newcomers developers if needed

#27

Or use a fallback MQTT webthing as I hacked for a demo:

Hints:

#28

It seems we won’t be seeing a Tasmota implementation for the foreseeable future, but on the ESPUrna side, it’s coming along nicely!

Thanks @rzr!

#29

Hi all.
Technically I introduced Itead Sonoff (with TASMOTA fw) to this discussion almost exactly one year ago.
It seems to me, that folks around this project are oriented to another direction.
After one year I run nearly 60 devices (with TASMOTA FW) within my home automation system. All of them work flawlessly.
Tasmota upgraded widely and range of compatible devices dramatically increased as well.
It works with HASSIO, Domoticz, OpenHUB, Yeti etc., but not with Mozilla IOT.

Simply said - you should use anything but MozillaIOT if you are using Tasmotized device.