@sirzlimz It may be stating the obvious but the photo shown is not a arduino processor but a ESP8266.
Therefore the I/O pins listed in the sketch refer to the GPIO pin number on the ESP8266.
So if PIN 2 is listed in the Sketch it refers to GPIO2 which is the pin marked D4 on the D1 mini module..
The photo shows the Data jumper connected to D2, So trying moving this to D4 with the original sketch.
@sirzlimz I have just tried this circuit out myself on a D1 module and the using the library listed from milesburton it does not work on the ESP8266 in parasitic mode.
If you move the jumper over for powered mode it will work fine.
Trying on an Arduino nano with the same device and breadboard it works fine in both modes.
So testing again and reading the data sheet on the DS18B20 and the section on "Powering the DS18B20" page 7 some insight can be obtained.
Anyway a quick fix is to put another 4.7K resistor in parallel with the first and the system should work with one sensor,
so two possible ways of connection are shown
Powered Mode with the Jumper to 5V, Recommended method, I always power my DS18B20's
This works with multiple devices, (I have just tried with 10 devices on the D1 [with multiple device sketch])
Parasitic Mode with two 4.7K resistors (this trick only works with one device on the bus)
@sirzlimz There are lots of pinout diagrams on the web like below.
For the the arduino use the GPIO number as the pin number
ie
GPIO5 --- marked D1 in Arduino IDE use 5
GPIO13-marked D7
@benhub Short answers, No, Yes, Yes
The regulator will use power if connected.
If your circuit is power hungry then removing the regulator will have limited effect.
The sparkfun schematic on the article that you listed notes to disconnect the regulator for low power, so the advice is consistent.
Unless you are using the genuine sparkfun versions of the pro-mini where the jumper can be cut then physically removing the regulator is recommended.
I made a simple adapter for Pro Minis, Used on it own for new boards with connection holes
If you slide on some dupont cable covers as a guide it makes it easy to program a soldered board
The Led is not actualy runing on AC. Part of the IC generates an low voltage AC signal (Nothing to do Mains Power) then other parts of the IC detect changes to this signal via the pair of diodes at the bottom, and then generate the two signals for the red and green leds.
The bicolor color led has a common terminal in the center and the two outer pins control the two outer pins power the red and green leds.
Utilizing a optocoupler has a safety advantage, as it isolates the power on the sensed unit from the mysensor node. It also allows systems using different control signal voltages to be interconnected.
If you have the arduino analogue pin connected to Pin3, where do you have the arduino GND connected?
As there is a relay that is connected in parallel to the the Upper LED drive transistor,
I recommend using a optocoupler and resistor connected to the relay terminals shown, as these connections are easy to solder wires to.
The resistor will need to be sized to match the voltage on the relay to limit current through the optocoupler led. 
The TLP222A are opto-Mosfet devices so ideal for powering LEDs and small Relays etc as they have a 500mA rating, and the price listed is good value.
However for your application, use the 4N35 that you already have.
Your diagram is reversed as you need to drive the led in the optocoupler from the relay coil connections.
Use the existing 10K as a pullup resistor at the input to the arduino,
On the relay side use a series resistor R1 of about 1Kohm for 12Vdc (expected from a 9Vac supply).
The pins on the sketch and the schematic do not match,
You need to be more careful on matching the items as it will make troubleshooting more difficult.
This sketch is a quick and dirty method, that does basically to work for me using OpenHAB as a controller. (only tested using LED outputs not with an actual computer).
If i was actually going to implement this, I would monitor the POWER LED on the computer for feedback and control of the pulses. ie for shutdown, try short pulse first for controlled shutdown and if not shutdown within expected time span, then preform a hard shutdown.
/*
* PC Power On/Off & Reset Sketch
* Power Pin Pulse = PC Starts if Already Off, *** PC Shutsdown if already on ## this is the operation of my Computer ##
* Power Pin 5 Seconds Low = PC Forced Shutdown
* Reset Pin Pulse Low = PC Reset (if already on)
*
* Using three child IDs
* 1 = Power On/Off
* 2 = Forced OFF
* 3 = Reset
*
* Version 1.0 2018-01-19
*/
/**
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2015 Sensnology AB
* Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* REVISION HISTORY
* Version 1.0 - Henrik Ekblad
*
* DESCRIPTION
* Example sketch showing how to control physical relays.
* This example will remember relay state after power failure.
* http://www.mysensors.org/build/relay
*/
// Enable debug prints to serial monitor
#define MY_DEBUG
//#define MY_NODE_ID AUTO
#define MY_NODE_ID 155 // my test Node ID, Comment out for Auto ID
// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95
// Enable repeater functionality for this node
#define MY_REPEATER_FEATURE // if you need the repeater function uncomment
#include <MySensors.h>
// Wait times
#define LONG_WAIT 500
#define SHORT_WAIT 50
#define PULSE_TIME 500UL // half a second
#define FORCED_TIME 5000UL // 5 seconds
boolean goPulse;
unsigned long pulseStartTime;
#define POWER_PIN 4 // Arduino Digital I/O pin number for PC Power control
#define RESET_PIN 5 // Arduino Digital I/O pin number for PC Reset control
#define RELAY_ON 1 // GPIO value to write to turn on attached relay
#define RELAY_OFF 0 // GPIO value to write to turn off attached relay
#define CHILD_ID_POWER 143 // these ID used for my test machine. change to suit ie 1
#define CHILD_ID_FORCEDOFF 144 // change to suit ie 2
#define CHILD_ID_RESET 145 // change to suit ie 3
boolean Status_Power = 0;
boolean Status_Forcedoff = 0;
boolean Status_Reset = 0;
boolean is_Power = 0;
boolean is_ForcedOff = 0;
boolean is_Reset = 0;
// Setup Messages
MyMessage msg(CHILD_ID_POWER,V_STATUS);
void before() {
// Set the pins to output mode
pinMode(POWER_PIN, OUTPUT);
pinMode(RESET_PIN, OUTPUT);
// Set the Pin states to known state
digitalWrite(POWER_PIN, RELAY_OFF);
digitalWrite(RESET_PIN, RELAY_OFF);
}
void setup() {
}
void presentation() {
// Send the sketch version information to the gateway and Controller
sendSketchInfo("Relay", "1.0");
wait(LONG_WAIT); // Give gateway time to Process
// Present child ids to conroller
present(CHILD_ID_POWER, S_BINARY, "PC Power on-off");
wait(SHORT_WAIT); // Give gateway time to Process
present(CHILD_ID_FORCEDOFF, S_BINARY, "PC Forced off");
wait(SHORT_WAIT); // Give gateway time to Process
present(CHILD_ID_RESET, S_BINARY, "PC Reset");
wait(SHORT_WAIT); // Give gateway time to Process
}
void loop() {
Serial.println();
Serial.print ("loop start ");
send(msg.setSensor(CHILD_ID_POWER).set( Status_Power));
send(msg.setSensor(CHILD_ID_FORCEDOFF).set( Status_Forcedoff));
send(msg.setSensor(CHILD_ID_RESET).set( Status_Reset));
wait(100000); // wait for testing
}
void receive(const MyMessage &message)
{
// We only expect one type of message from controller. But we better check anyway.
if (message.type==V_STATUS)
switch (message.sensor) {
case CHILD_ID_POWER:
is_Power = message.getBool();
Serial.print("incoming change for Power:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println((is_Power ? "On":"Off"));
powercmd(); // process pulses etc in subroutine
break;
case CHILD_ID_FORCEDOFF:
is_ForcedOff = message.getBool();
Serial.print("incoming change for FORCED Power OFF:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println((is_ForcedOff ? "On":"Off"));
forcedcmd();
break;
case CHILD_ID_RESET :
is_Reset = message.getBool();
Serial.print("incoming change for Reset:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println((is_Reset ? "On":"Off"));
resetcmd();
break;
default:
Serial.print("Unknown/UnImplemented message type: ");
Serial.println(message.type);
}
}
void powercmd() {
// process power pin
if (is_Power != Status_Power) {
digitalWrite(POWER_PIN, RELAY_ON);
delay(PULSE_TIME); // delay used as pulse time is short & multiple processes are not expected
digitalWrite(POWER_PIN, RELAY_OFF);
Status_Power = is_Power;
}
}
void forcedcmd() {
// process forced power off command
if (is_ForcedOff = 1 ) {
digitalWrite(POWER_PIN, RELAY_ON);
delay(FORCED_TIME); // delay used as multiple processes are not expected, quick and dirty
digitalWrite(POWER_PIN, RELAY_OFF);
Status_Forcedoff = 0; // reset status for next time
Status_Power = 0; // power status also reset if power shutoff
}
}
void resetcmd() {
// process reset command
if (is_Reset != 1 ) {
digitalWrite(RESET_PIN, RELAY_ON);
delay(PULSE_TIME); // delay used as multiple processes are not expected, quick and dirty
digitalWrite(RESET_PIN, RELAY_OFF);
Status_Reset = 0;
}
}
@robert the NUMBER_OF_RELAYS is already defined in your sketch, just use as pasted.
I use OpenHAB so i just tried to install Dormotiz and was supreised that it took less than a an hour to install and get working with the relays. (Most of that time was trying to get them to shown up on the dashboard)
Dormotiz is communication fine with my node and i can switch on and off the relays from the Dashboard
In the sort time i have checked i do see that the Last Seen time only changes when i change the state of the relay.
So your program that you posted works for me with both my normal OpenHAB and the new test Domoticz.
I think that i may be miss understanding your actual problem.
@mela You are presenting the devices as Relay Child 1, and Temperature sensors as Child Ids 5 and 6.
But when sending you are sending the temperatures as Child Ids 0 and 1
Change the following send line
// Send in the new temperature
send(msg.setSensor(i).set(temperature,1));
to
// Send in the new temperature
send(msg.setSensor(i+5).set(temperature,1));
so the send function matches the presentation values.
@OldSurferDude You are getting regular GWT:TSA:ETH OK message which i do not and you have no
MSG SENT lines
Which MQTT broker are you using?
my test setup which i hope matches yours is:
MySensors 2.3.2 & ESP8266 core 2.7.4
ESP8266 Node MCU with sketch GatewayESP8266MQTTClient
MY_BAUD_RATE 9600
MY_MQTT_USER & MQTT_PASSWORD commented out
MY_CONTROLLER_IP_ADDRESS 192, 168, 1, 195 address of the MQTT broker
MY_CONTROLLER_URL_ADDRESS "MQTT-TEST-W10" commented out Use IP or URL not Both
MY_PORT 1883
MQTT Broker
Mosquitto 2.0.15 running as a service on a windows 10 machine
listener 1883 anonymous access
URL MQTT-TEST-W10
When connected to the MQTT Broker and receiving messages from a node the gateway shows
09:48:18.962 -> 718935 TSF:MSG:READ,254-254-0,s=1,c=1,t=16,pt=2,l=2,sg=0:0
09:48:19.010 -> 718997 GWT:TPS:TOPIC=mygateway5-out/254/1/1/0/16,MSG SENT
09:48:19.104 -> 719059 TSF:MSG:READ,254-254-0,s=1,c=1,t=15,pt=1,l=1,sg=0:1
09:48:19.149 -> 719121 GWT:TPS:TOPIC=mygateway5-out/254/1/1/0/15,MSG SENT
09:48:19.198 -> 719182 TSF:MSG:READ,254-254-0,s=255,c=3,t=0,pt=1,l=1,sg=0:83
09:48:19.292 -> 719246 GWT:TPS:TOPIC=mygateway5-out/254/255/3/0/0,MSG SENT
if a message is sent to the broker the gateway shows
10:03:54.285 -> 1654209 GWT:IMQ:TOPIC=mygateway5-in/254/255/1/0/15, MSG RECEIVED
10:03:54.331 -> 1654279 TSF:MSG:SEND,0-0-254-254,s=255,c=1,t=15,pt=0,l=1,sg=0,ft=0,st=OK:1
10:03:54.423 -> 1654358 TSF:MSG:READ,254-254-0,s=1,c=1,t=16,pt=2,l=2,sg=0:1
10:03:54.471 -> 1654421 GWT:TPS:TOPIC=mygateway5-out/254/1/1/0/16,MSG SENT
10:03:54.565 -> 1654483 TSF:MSG:READ,254-254-0,s=1,c=1,t=15,pt=1,l=1,sg=0:1
10:03:54.611 -> 1654546 GWT:TPS:TOPIC=mygateway5-out/254/1/1/0/15,MSG SENT
@OldSurferDude You should leave them commented if not required.
I have just tested with a new install on windows of mosquitto with config file for anonymous access and it is working fine with them commented out.
what do your gateway debug logs look like?
@yourry for an example of array usage see Temperature Sensors build page.
MyMessage msgInA(0, V_WATT); // only one message required
#define NSENSORS 6
//Read values and send to gateway
for (int i=0; i<NSENSORS; i++)
{
watt[i] = (emon[i].calcIrms(1480))*230*0.9;
send(msgInA.setSensor(i).set(watt[i], 1)); //setSensor(i) is the magic
}
@OldSurferDude have you set the MQTT user and MQTT passwords in the sketch and uncommented them as well?
// Enable these if your MQTT broker requires usenrame/password
//#define MY_MQTT_USER "username"
//#define MY_MQTT_PASSWORD "password"
// Enable these if your MQTT broker requires usenrame/password
#define MY_MQTT_USER "MQTTusername2022"
#define MY_MQTT_PASSWORD "MQTTpassword2022"
what does your debug log look like?
This sample is not connected correctly to the MQTT Broker
10:33:26.151 -> dhcp client start...
10:33:26.151 -> 341 TSM:INIT:GW MODE
10:33:26.199 -> 364 TSM:READY:ID=0,PAR=0,DIS=0
10:33:26.199 -> 396 MCO:REG:NOT NEEDED
10:33:26.339 -> 505 GWT:TPC:CONNECTING...
10:33:27.365 -> 1533 MCO:BGN:STP
10:33:27.365 -> 1551 MCO:BGN:INIT OK,TSP=1
10:33:27.412 -> 1579 TSM:READY:NWD REQ
10:33:27.412 -> 1606 ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
10:33:28.671 -> scandone
10:33:35.993 -> pm open,type:2 0
10:33:44.664 -> 18861 TSF:MSG:READ,254-254-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
10:33:44.758 -> 18924 TSF:MSG:BC
10:33:44.758 -> 18942 TSF:MSG:FPAR REQ,ID=254
10:33:44.804 -> 18973 TSF:PNG:SEND,TO=0
10:33:44.804 -> 18998 TSF:CKU:OK
10:33:44.851 -> 19016 TSF:MSG:GWL OK
10:33:45.459 -> 19646 TSF:MSG:SEND,0-0-254-254,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
10:33:46.671 -> 20876 TSF:MSG:READ,254-254-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
10:33:46.766 -> 20939 TSF:MSG:PINGED,ID=254,HP=1
10:33:46.813 -> 20980 TSF:MSG:SEND,0-0-254-254,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
10:33:46.860 -> 21057 TSF:MSG:READ,254-254-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
This is working correctly
10:36:34.908 -> dhcp client start...
10:36:37.655 -> ip:192.168.1.202,mask:255.255.255.0,gw:192.168.1.254
10:36:37.702 -> 7014 GWT:TPC:IP=192.168.1.202
10:36:37.702 -> 7100 GWT:RMQ:CONNECTING...
10:36:37.749 -> 7144 GWT:RMQ:OK
10:36:37.795 -> 7161 GWT:TPS:TOPIC=mygateway4-out/0/255/0/0/18,MSG SENT
10:36:44.792 -> pm open,type:2 0
10:38:56.629 -> 146027 TSF:MSG:READ,254-254-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
10:38:56.723 -> 146091 TSF:MSG:BC
10:38:56.723 -> 146109 TSF:MSG:FPAR REQ,ID=254
10:38:56.770 -> 146142 TSF:PNG:SEND,TO=0
10:38:56.770 -> 146168 TSF:CKU:OK
10:38:56.816 -> 146187 TSF:MSG:GWL OK
10:38:57.655 -> 147013 TSF:MSG:SEND,0-0-254-254,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
10:38:58.683 -> 148042 TSF:MSG:READ,254-254-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
10:38:58.730 -> 148105 TSF:MSG:PINGED,ID=254,HP=1
10:38:58.776 -> 148148 TSF:MSG:SEND,0-0-254-254,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
10:38:58.869 -> 148226 TSF:MSG:READ,254-254-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
10:38:58.916 -> 148294 TSF:MSG:SEND,0-0-254-254,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
10:38:59.010 -> 148375 TSF:MSG:READ,254-254-0,s=255,c=0,t=17,pt=0,l=11,sg=0:2.4.0-alpha
10:38:59.058 -> 148450 GWT:TPS:TOPIC=mygateway4-out/254/255/0/0/17,MSG SENT
10:38:59.151 -> 148515 TSF:MSG:READ,254-254-0,s=255,c=3,t=6,pt=1,l=1,sg=0:0
10:38:59.197 -> 148578 GWT:TPS:TOPIC=mygateway4-out/254/255/3/0/6,MSG SENT
10:39:00.923 -> 150319 TSF:MSG:READ,254-254-0,s=255,c=3,t=11,pt=0,l=14,sg=0:MockMySensors
10:39:01.017 -> 150398 GWT:TPS:TOPIC=mygateway4-out/254/255/3/0/11,MSG SENT
10:39:01.064 -> 150462 TSF:MSG:READ,254-254-0,s=255,c=3,t=12,pt=0,l=4,sg=0:v0.5
10:39:01.157 -> 150529 GWT:TPS:TOPIC=mygateway4-out/254/255/3/0/12,MSG SENT
10:39:01.949 -> 151337 TSF:MSG:READ,254-254-0,s=1,c=0,t=0,pt=0,l=12,sg=0:Outside Door
10:39:02.044 -> 151410 GWT:TPS:TOPIC=mygateway4-out/254/1/0/0/0,MSG SENT
10:39:02.091 -> 151471 TSF:MSG:READ,254-254-0,s=255,c=3,t=26,pt=1,l=1,sg=0:2
10:39:02.184 -> 151542 TSF:MSG:SEND,0-0-254-254,s=255,c=3,t=27,pt=1,l=1,sg=0,ft=0,st=OK:1
10:39:02.699 -> 152055 TSF:MSG:READ,254-254-0,s=255,c=3,t=0,pt=1,l=1,sg=0:83
@OldSurferDude If connecting to a MQTT Broker i would have expected you to use the GatewayESP8266MQTTClient sketch.
as this is already setup with correct Port 1883 for MQTT and the publishing and subscription topics.
I did a quick test of a GatewayESP8266MQTTClient sketch with mosquitto and it works fine for me.
@OldSurferDude @dpcons Hi all,
The sample sketch could also be found using (File -> Examples -> MySensors -> Esp8266Gateway
As MySensors version 2.3.2 and ESP8266 core 3.0.2 combination does not work you need to change one or the other versions.
The simplest is to roll back the ESP8266 Core version to 2.7.4 and keep the MySensors 2.3.2 version
(Tools -> Board -> Board Manager)
Enter ESP8266 in search bar, then click within the ESP8266 data info box, click the select version pulldown.
Select 2.7.4 and then click Install.
Other option is to update the MySensors library to the development version 2.4.0-Alpha but that has to be done manually.
@dpcons I assembled a board copied from yours for testing.
I could replicate the problem. It is with the ESP core version and the MySensor Version
MySensors version 2.3.2 and ESP8266 core 3.0.2 does not work,
MySensors version 2.3.2 and ESP8266 core 2.7.4 works
Mysensors development version 2.4.0-Alpha and newest ESP8266 core 3.0.2 also works
So you can either update the esp core to older version 2.7.4, or install the development version of MySensors 2.4.0-Alpha
@dpcons As you are seeing no serial debug data. Have you checked that your serial data monitor is set for the same baud rate as set in the sketch (9600 on MySensors GatewayESP8266 sketch) as other sketches use default 115200
What troubleshooting steps have you all ready taken?
I have loaded your sketch onto a mega2560 and looked at the serial output.
the binary switch child's 20 and 21 are switching.
0;20;1;0;16;1
0;21;1;0;16;1
0;21;1;0;16;0
0;20;1;0;16;0
0;21;1;0;16;1
0;20;1;0;16;1
0;21;1;0;16;0
0;21;1;0;16;1
0;21;1;0;16;0
0;21;1;0;16;1
0;20;1;0;16;0
0;20;1;0;16;1
have you checked this?
also why do you have all MY_INCLUSION defines active when there is no radio attached?
// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
#define MY_INCLUSION_BUTTON_FEATURE
// Inverses behavior of inclusion button (if using external pullup)
//#define MY_INCLUSION_BUTTON_EXTERNAL_PULLUP
// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60
// Digital pin used for inclusion mode button
#define MY_INCLUSION_MODE_BUTTON_PIN 3
and you have the repeater function enabled
// Enable repeater functionality for this node
#define MY_REPEATER_FEATURE
this is sloppy programming and can cause problems.
Have you checked the basic things like the connections to the inputs?
You have the internal PULLUP enabled so the input signal should switch to ground.
try changing
moistureLevels[i] = map(moistureLevel,0,650,0,99); // The maximum voltage output of the capacitive sensor is 3V, so since we're measuring 0-5v about 614 is the theoretical highest value we'll ever get.
to
moistureLevels[i] = map(moistureLevel,325,650,99,0); // The maximum voltage output of the capacitive sensor is 3V, so since we're measuring 0-5v about 614 is the theoretical highest value we'll ever get.