Roadmap Suggestions

[patbeirne]

Theo,

Your work here is great. Thank you so much.

Last month I built a wishlist of things I was going to add to the project: 1) wifimanager 2) more status commands 3) telemetry messages 4) compatibility with DHT22 and Elecrodragon

I see that you've already added 1) and 2) THANK YOU

2) Would it make sense to have the status messages come back in JSON format? That would allow future changes to be backward compatible, but might break existing apps. Example: status 3 -> LOG: Seriallog 2, Syslog 0, LogHost p600, SSId B31, Password omnibus would change to status 3 -> {"LOG" : { "Seriallog" : 2, "Syslog" : 0, "LogHost" : "p600", "SSId" : "B31", "Password" : "omnibus" } }

3) I really like the way you're using "cmnd/..." and "stat/..." as prefixes. This makes my server code easy to write. I propose adding the "tele/..." prefix for periodic signals (telemetry) from the device. For example, you currently send a HEARTBEAT as stat/device_name/HEARTBEAT %d Under the telemetry proposal, you could send tele/device_name/HEARTBEAT %d I originally added this for my DHT22 devices to send back temperature and humidity (and a time-stamp)

tele/Piche_DHT/TEMPERATURE 22.1
tele/Piche_DHT/HUMIDITY 58.3
tele/Piche_DHT/TIME 2016-08-29T09:33:35

4) I have ported your code over to the ElectroDragon and to an ESP-01+DHT22 temperature/humidity monitor. The ElectroDragon requires two control bits for the two relays. It only has one LED. And the control buttons are inside the protective cabinet. So it's a little more tricky to install; once it's configured, it works very well.

The DHT22 device needs to simply report temperature/humidity on a certain clock tick.

So I propose adding

cmnd/device_name/power2 0/1/on/off    # control ElectroDragon
cmnd/device_name/topic2 topic_name    # I stole topic2 for the 2nd relay
cmnd/device_name/temperature 0/1      # get temperature on demand
cmnd/device_name/humidity 0/1         # get humidity on demand
cmmd/device_name/telemetry_period number_of_seconds  # 0=no telemetry
stat/device_name/POWER2 state         # response to a set/reset/query
stat/device_name/TOPIC2 topic_name
stat/device_name/TELEMETRY_PERIOD number_of_seconds   # response to a set/disable/query
tele/device_name/TEMPERATURE 21.2
tele/device_name/HUMIDITY 45.3
tele/device_name/POWER ON
tele/device_name/POWER2 ON
tele/device_name/TIME YYYY-MM-DDTHH:MM:SS  # sent at the end of a telemetry cluster

I will be happy to write&merge code to implement this later on this year.

[arendst]

Pat,

thanx for your thoughts on this project. I like some of your ideas and I will try implementing it.

I prefer to keep the updates in hand myself as I want to have the possibility to enable/disable features as they might burden the ESP altogether to much. I noticed tricky webserver implementations so I stayed away from it as long as possible but finally decided to implement it for those who want/need it.

I must say the web upload feature is a nice one as it is much quicker than my ota using web server implementation.

Rgrds, Theo.

[patbeirne]

Theo,

Ok, I totally understand wanting to keep changes in hand. I look forward to your future work.

Just for your reference, if you decide to implement the DHT22 & ElectroDragon, I had these defines in my project.

#define SONOFF                1
#define DHT22                 2
#define ELECTRO_DRAGON        3
#define MODULE                DHT22

#if MODULE == ELECTRO_DRAGON
  #define PROJECT              "ElectroDragon_DualRelay"
  #define DEVICE_NAME          "ElectroDragon dual relay module"
#elif MODULE == SONOFF
  #define PROJECT              "Sonoff"
  #define DEVICE_NAME          "Sonoff relay module"
#elif MODULE == DHT22
  #define PROJECT              "DHT22"
  #define DEVICE_NAME          "DHT22 temp/humidity sensor" 
#endif

#if MODULE == ELECTRO_DRAGON
  #define LED_PIN                16           // NodeMCU
  #define RELAY_PIN             13            // GPIO 13 = Red Led and Relay (0 = Off, 1 = On)
  #define RELAY2_PIN            12            // these are reversed for easier wiring
  #define DHT_PIN               14
  #define KEY_PIN               2            
  #define KEY2_PIN              0
    // programming header 5V/3V/gnd/
#elif MODULE == SONOFF
  #define LED_PIN               13        // green part of the LED (the red part is tied to relay)
  #define KEY_PIN               0         // general usage and programming
  #define RELAY_PIN             12
    // programming header 1:3.3V 2:rx 3:tx 4:gnd
#elif MODULE == DHT22
  #define LED_PIN               0
  #define DHT_PIN               2
  #define KEY_PIN               0
  #define RELAY_PIN             12    // not used on an esp-01
#else
  #error "module not defined"
#endif

[patbeirne]

Taking this just one tiny step farther, if anyone out there wants to add ElectroDragon or DHT22 compatibility to Theo's code, here's a way that should survive a few revisions.

Download/clone Theo's main branch and add the one-liner #include "porting.h" immediately after the line where KEY_PIN is defined. In this revision 1.0.26, that would be after line 61; this will vary with revisions.

Then create this file porting.h in the directory with your sketch:

#undef KEY_PIN
#undef REL_PIN
#undef LED_PIN
#undef APP_NAME
#undef PROJECT

#define SONOFF                1
#define DHT22                 2
#define ELECTRO_DRAGON        3
#define MODULE                ELECTRO_DRAGON 

#if MODULE == ELECTRO_DRAGON
  #define PROJECT              "ElectroDragon_DualRelay"
  #define APP_NAME          "ElectroDragon dual relay module"
#elif MODULE == SONOFF
  #define PROJECT              "Sonoff"
  #define APP_NAME          "Sonoff relay module"
#elif MODULE == DHT22
  #define PROJECT              "DHT22"
  #define APP_NAME          "DHT22 temp/humidity sensor" 
#endif

#if MODULE == ELECTRO_DRAGON
  #define LED_PIN               16           // NodeMCU
  #define REL_PIN               12            // GPIO 13 = Red Led and Relay (0 = Off, 1 = On)
  #define RELAY2_PIN            13            // these are reversed for easier wiring
  #define DHT_PIN               14
  #define KEY_PIN               2            
  #define KEY2_PIN              0
    // programming header 5V/3V/gnd/
#elif MODULE == SONOFF
  #define LED_PIN               13        // green part of the LED (the red part is tied to relay)
  #define KEY_PIN               0         // general usage and programming
  #define REL_PIN               12
    // programming header 1:3.3V 2:rx 3:tx 4:gnd
#elif MODULE == DHT22
  #define LED_PIN               0
  #define DHT_PIN               2
  #define KEY_PIN               0
  #define REL_PIN               12    // not used on an esp-01
#else
  #error "module not defined"
#endif

Now go to line 10 of porting.h and pick your variant.

Notice: This build only operates one of the two relays on the Electrodragon. I use relay 2 because it's much easier to wire into the plastic cabinet.

Notice: the DHT22 variant does nothing at this point. But it's a framework into which you could easily merge the DHT22 arduino library.

[patbeirne]

Ooops. On the ElectroDragon the LED_PIN in inverted, so it lights when the relay is off, and is not lit when the relay is on.

[arendst]

Pat,

I'm currently implementing your defines in my code as it seems to be very simple.

Looking at the Dragon schematics I also noticed that the led is inverted. I'll make a define in my code and will fix it for the dragon.

From your defines it seems to me you are controlling relay 2 from button 1?

I might be implementing the DHT22 code also....

Rgrds, Theo.

[patbeirne]

Yes, you are correct on both counts.

1) The LED on the dragon is inverted

2) My defines make the ElectroDragon relay #2 as the principal device (relay and button and the coupled LED) This is because it's MUCH easier to wire up relay #2. The other relay (#1) requires thin and angled wires. I've never had cause to use 2 relays (yet).

Pat

[patbeirne]

One more thing I forgot to ask for in my wish list above:

I have an Android MQTT client that cannot send a null message. [MQTT Dashboard] So, when I want to query the state of POWER, SSID, etc, it get's tricky. With the existing code, I can fool it by sending a "-1".

But it would be cleaner if the payload is "?" to query the existing state.

For example: existing method mosquitto_pub -h mqtt.myserver.com -t cmnd/den_sonoff2/power -n sends a null message

alternate method (for clients which cannot send null message) mosquitto_pub -h mqtt.myserver.com -t cmnd/den_sonoff2/power -m ?

[arendst]

The alternate method has just been implemented ;-)

Still working on the DHT code.

[patbeirne]

You're so fast! That's great. It'll really help getting a short status message.

[patbeirne]

For anyone who's reading, since we don't have a Wiki yet....

REMOTE BUTTON

I have a cabin that is remote from my house, and I'm using a Sonoff to turn on/off the heaters remotely, so the place can be warm when I get there. The Sonoff(heater control) is located near the fuse box, and it controls a relay which switches the 120V/30A to the heaters.

It's awkward to get at the Sonoff(heater control) physically, so when I'm using it, I use MQTT commands to control the heaters. But I have some family members that are not comfortable with MQTT usage.

So I built a small ESP-01 and a DHT22 and a push button, and ported Theo's code to it. I use the cmnd/my_DHT/buttontopic to set the mqtt command to control the heaters. Yes, you can program Theo's sonoff so that the button sends out any arbitrary command. In this case, I'm using the button to control the other sonoff. This ESP+DHT device is in the common area of the cabin, so my family members can simply push the button to toggle the heater.

In other words, I'm using one trivial (DHT+button) wifi device to control the other (sonoff+heater relay). This technique uses Theo's flexible design, since buttontopic can be made different from topic.

Pat

P.S. As an added bonus, I can monitor the temperature of the cabin while I'm not there. Which can be handy when the freezing weather comes. I use an old cell phone + cheap-data-only-SIM-card to get network connection.