@macieiks I got an identical Error last week after upgrading to Arduino 1.8.0. Solution is:
https://forum.mysensors.org/topic/4680/mysensors-2-0-ethernet-gateway-atmega-w5100-restart-all-time/4
simple: If you are running AVR board defs > 1.6.11, downgrade to 1.6.11 and the issue should be solved. (from @tekka).
If someone is interested: same Error for ENC28J60 Ethernet module, resolved with downgrading board definitions to 1.6.11.
@Reza Your code isn´t easy to understand. More Comments within your code would be very helpful.
So I will try a little mind reading.....
Basic concept seems to be decoupling switches/pushbuttons from the relais part and to control the relais action through your controller.
Management of switches/pushbuttons is done in loop().
"Master of states" is your controller (software).
Actions are performed by receive().
At last a clean soloution - but some parts aren´t that clean.
The only reference to stateX is within receive() directly before digital_write(X). So any change to stateX from within the sketch will not have any effekt. So the introduction of the stateX variable isn´t actually necessary.
digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
should work to. This eliminates thes risk of double originals which can get very tricky if things go wrong. (i.e. there should be only one set of stateX variables in your system because keeping copied sets tidy is a huge amount of work and prone to errors).
In the first part of loop() you try to instantiate some basic mechanisms to accomplish this mission but I fear it will not succeed.
Within loop you begin with a chain of modulo-operations which might be intended to send the state variable to your controller once every hour (?) with 1 second interval. This will fail eternally if your loop starts accidentally with millis() at xxxxxx1 and loop duration is xxxxxx2. The remainder of % operation will always be 1 (or more) but never zero. Precise timing down to 1 millisecond would be too critical to little errors and is not necessary.
Spacing send() to one second should not be necessary either - MySensors framework can deal with lot of send() in a row.
So maybe a statement like
if (millis() >= lasttime+INTERVALL) {.....}
could fit your needs. It isn´t that precise - but precise enough and robust.
if (trigger == 0) {...;trigger=1;}
This part is executed only once because you never reset trigger to zero. If you intend to reset your controller variables you might move this part to setup() - or better leave it to your controller.
But if you omit stateX copying this whole section could be skipped.
The rest of loop() consists of switch management which seems ok to me. Nevertheless a little proposal for optimisation:
send(msgA.set(stateA ? true : false), true);
There is no really need for the trinary operator ? because stateA is bool, it may be send directly like
send(msgA.set(stateA ), true);
debouncerA.update();
I am not very familiar with debounce(). But omitting "&&valueA==0" will cause your statement to react to pressing your button as well as to releasing your button. So this statement will act twice on one keystroke -- so far I remember the debounce() function.
Because stateA is not likely to be changed in this short amount of time, this statement will send stateA twice - which causes unnecessary traffic.
These are surely no crucial points but I think the sketch woud be more robust.
wdt_enable(WDTO_4S);
Please don´t do this - it may have terrible side effects and may make you mad while searching for errors.
So over all your sketch isn´t that bad for a first proof of concept and should be functional for your basic needs.
So missing send should be due to the qualitiy of your connection. Maybe a longer log of debug messages (both sides?) would be helpful.
.
@tekka This is very interesting. I think i will review my own system - just for curiosity. Thank you for this explanation.
@Reza: don´t get desperate. I think you are not a beginner - but if you are - your learning curve is fairly steep.
As mentioned before, sometimes it is better to step backwards and look from the distance.
If you aren´t too annoyed, I would offer to guide you to a working two-arduino system. (and I am sure @tekka will give advice if necessary) From there you will probably manage it on your own.
Started correctly MySensors will supply you with a lot of fun -- but today it is not funny for you.
So put away this stuff for today, go fishing and have a cold one.
Tomorrow (or Wednesday, because I don´t know my schedule for tomorrow now) we will build up things in an ordered way. (and please don´t scavenge your current gateway, I think it is the source of all evil and I am too curious about the reason).
footnote: if you are worried about your English (I am not) - give google translate a try - if available for your language
@Jan-Gatzke You are welcome.
@Reza : don´t worry, there will be a simple solution.
I´m in a hurry at the moment, I was ordered to do some party tonight. If my supreme command detects my current activities I will have very bad Karma for the next days.
To whom it may already apply: Happy new Year!! 
if (applies == 0) {
wait.some(hours);
read.again();
}
@Reza:
I tried to reproduce the errors shown by your log.
Part of the errors could be reproduced.
So if you are leaving range of stable connections, node will try to get an new parent (within range). So broadcasting for new parent is "normal". As long as there is no valid connection node will reject sending messages because "Transport Not Ready". So this is "normal", too.
Leaving range resulted in one or two NACK, then connection died quietly. I never got this amount of NACK you got.
I could not reproduce !TSF:MSG:LEN:0!=8 or something similar. This means the message has been crippled (possibly).
Reviewing logs and testing on my configuration revealed no clue to defective Chips (in regard to NRF24L01). Chips could be fake though, but at least software functions seem to be ok.
Fake NRF modules are reported to have very varying (worse) connection distances, sometimes down to a few (possibly only one) meter(s). Maybe -- may be not.
There are two major differences between our setups. I am currently not working with ACKs, I will test this tomorrow.
Second - I got no actual relays connected (only LEDs). You reported transmission break down simultaneously to pressing switches at higher rate. Are you supplying DC for relays from Arduino or from separate DC-supply? Have you made any arrangement preventing inductive spikes (ferrite rings, self-induction recuperation diode etc) ?
If you simply unhook your relays and try again - you get better results? (since your non-inductive sensors work well).
If this will turnout true - you may give Solid-State-Relais a try.
@macieiks
for the sake of completeness - you do not have to downgrade your complete Arduino IDE, just "tweak" boards definitions. Board versions are not necessarily numbered according to Arduino version.
Sorry - I couldn´t get Enlish version at speed.
I probably reads "Tools"->"Board"->"Boardmanager"
I got 1.6.11 installed- so it is not available in drop down list.
Choose your desired version, hit "Install", wait a fairly long time and you are done.
For testing basic functions there exists another (rather crude) way - the serial binding offerd by OpenHAB. Adding :
String Arduino "Arduino [%s]" {serial="COM6"}
to an "items" file will do the trick. Accordingly a "rules" file should be expanded by something like :
rule SplitMessage
when
Item Arduino changed
then
<do some relevant processing>
Using MySensors 1.4b (proMini, Uno, Mega.Leonardo) and OpenHab 1.5 (Windows 7 Notebook) produced very reliable results with SerialGateway connected via USB.
You have to compile the sketches with Baudrate set to 9600 because OpenHAB deals only with this Baudrate (mentioned somewhere in the OpenHAB Documentation).
So in Mysensors.h replace :
#define BAUD_RATE 115200
with
#define BAUD_RATE 9600
Because OpenHAB is not prepared to distribute NODE_IDs, you should hardcode this NODE-IDs. This decreases flexibility, but it is acceptable to some degree.
This approach works well for reading sensordata as for writing to actuators. Currently I am using eigth Nodes (including Repeater) with serveral children (e.g. multiple DS18B20, multiple Door contacts, Motionsensor, DHT22 etc). Until now I haven´t enconterd serious problems.
@Joakim-Johansson
I got a bunch of CH340G UNOs, some CH340G Nanos and some CH340G USB-serial converters (for use with Arduino Pro Mini ). Since i bought them (maybe 2015) until today they worked flawless under Windows 7, Windows 10 and Ubuntu (various versions). No trouble with drivers or similar.
@flopp I got kind of similar errors due to insufficient supply voltage stability (e.g. drive NRF24L01 from nano´s 3.3V source which is not robust enough - most of the time).
So far your problem resembles mine - it is "read 0-0-0 ...". A message from Node 0, last forwarded by Node 0 is ok, but this message addressed to Node 0 is certainly not ok. So probably the NRF made rubbish from received messages. At this time I got some missing "FIND PARENT" and inconsistent "Version mismatch" -- which are receiving problems - I think. It seems the receive capabilities of NRF are very sensitive to voltage drops. Similar to your problem sending was not compromised.
So adding a little buck converter for 3.3 V (http://www.ebay.de/itm/201280523226?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT or http://www.ebay.de/itm/201662468680?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT ) and supplying it from nano´s 5V (=USB, 500mA) made the errors vanish.
Another solution could be adding a capacitor - I haven´t tried it yet.
A quick hack for Christmas may be to hook up the NRF to two fresh AA-cells (don´t forget common ground). They will drain relative quickly, but they will last long enough to identify the problem.
Merry Christmas and good luck.....
@C.r.a.z.y. , maybe the Node-Id Delaration might be ineffektive. The output of OpenHab says your node identifies itself as Node 0 (Node 0 should be the Gateway itself). You should consider to give Static ID´s like:
#define NODE_ID 100
gw.begin(incomingMessage, NODE_ID, true);
So far I understand your sketch, yout try to assign a Node-id in the declaration statement
MySensor gw(100);
I´m not sure if this works. It will be safe to change it to
MySensor gw();
unless you got some very special hardware.
If the Node-Id is assigned properly, your code example should work fine.
@SuperKris : you should consider adding the "sending" routines for MySensors. Maybe dissecting the Binary Switch Example would be a better startingpoint than the RelaySketch.
I tried to integrate these routines into your template. Unfortunately I can´t test this sketch due to the lack of the Keypad. At least the sketch compiles without error.
// ##### SET PROJECT NAME AND VERSION #####
#define ProjectName "Schuur controller"
#define ProjectVersion "0,2"
// ##### SET MYSENSOR SETTINGS BEFORE INCLUDIGN LIBRARY #####
#define MY_DEBUG // Enable debug prints to serial monitor
#define MY_RADIO_NRF24 // Enable and select radio type attached
#define MY_REPEATER_FEATURE // Enabled repeater feature for this node
// ##### INCLUDE LIBRARYS #####
#include <SPI.h>
#include <MySensors.h>
#include <Bounce2.h>
#include <Keypad.h>
// ##### Child-IDs for "Virtual"Switches #####
#define CHILD_ID_V1 1
#define CHILD_ID_V2 2
#define CHILD_ID_V3 3
#define CHILD_ID_V4 4
#define CHILD_ID_V5 5
// ##### KEYPAD SETUP #####
const byte ROWS = 4; // Four rows
const byte COLS = 3; // Three columns
// Define the Keymap
char keys[ROWS][COLS] = {
{'1', '2', '3'},
{'4', '5', '6'},
{'7', '8', '9'},
{'A', 'B', 'C'}
};
// Connect keypad ROW0, ROW1, ROW2 and ROW3 to these Arduino pins.
byte rowPins[ROWS] = { A0, A1, A2, A3 };
// Connect keypad COL0, COL1 and COL2 to these Arduino pins.
byte colPins[COLS] = { A4, 1, 0 }; //if you got any spare pins - change 0 and 1 accordingly e.g. { A4, 8, 9 }
// or see below
// Create the Keypad
Keypad kpd = Keypad( makeKeymap(keys), rowPins, colPins, ROWS, COLS );
// ##### DEFINE I/O PINS #####
//#define IoPin1 4 // Arduino Digital I/O pin number for I/O 1
#define IoPin2 3 // Arduino Digital I/O pin number for I/O 2
//#define IoPin3 6 // Arduino Digital I/O pin number for I/O 3 / Pin 6 seems to be unused
#define IoPin4 5 // Arduino Digital I/O pin number for I/O 4
#define IoPin5 8 // Arduino Digital I/O pin number for I/O 5
#define IoPin6 7 // Arduino Digital I/O pin number for I/O 6
#define IoPin7 19 // Arduino Digital I/O pin number for I/O 7
// ##### BOOLEANS FOR VIRTUAL SWITCHES #####
bool VirtalSwitch1; // Boolean (status) for virtual switch 1 (controlled by keypad)
bool VirtalSwitch2; // Boolean (status) for virtual switch 2 (controlled by keypad)
bool VirtalSwitch3; // Boolean (status) for virtual switch 3 (controlled by keypad)
bool VirtalSwitch4; // Boolean (status) for virtual switch 4 (controlled by keypad)
bool VirtalSwitch5; // Boolean (status) for virtual switch 5 (controlled by keypad)
// define Message"Containers" to communicate with Gateway
MyMessage msgV1(CHILD_ID_V1,S_LIGHT);
MyMessage msgV2(CHILD_ID_V2,S_LIGHT);
MyMessage msgV3(CHILD_ID_V3,S_LIGHT);
MyMessage msgV4(CHILD_ID_V4,S_LIGHT);
MyMessage msgV5(CHILD_ID_V5,S_LIGHT);
void setup()
{ // ##### PIN SETUP (FOR TESTING ONLY #####
pinMode(IoPin4, OUTPUT); // use I/O 4 as output for relay module
digitalWrite(IoPin4, HIGH); // and set is HIGH so relay stays off
// ###### VARIOUS SETTINGS ######
Serial.begin(115200); // SERIAL PRINT MUST BE DEACTIVATED TO MAKE THE WHOLE KEYPAD WORK if Pin 0 and Pin1 are used for ColAdressing,
// maybe pin 8,9,10 would be preferable with respect to compact wiring (e.g. byte colPins[COLS] = { 8,9,10 }; )
// without pin 0 and one used, you can do some serial debugging, which is very helpful.
}
void loop()
{
char key = kpd.getKey(); // Get key from keypad (if pressed)
if (key) { // compare key (defined in keypad setup)
switch (key) { // with multiple multiple options below
case '1': // If the pressed key compares with "1"
VirtalSwitch1 = true; // Change te state of boolean VirtalSwitch1 to true
send(msgV1.set(1)); // sending virtual switch state to Gateway
Serial.println("1"); // Debug code. Print "1" to show that button 1 was pressed
break; // End of code for button 1
case '4': // If the pressed key compares with "4"
VirtalSwitch1 = false; // Change te state of boolean VirtalSwitch1 to false
send(msgV1.set(0)); // sending virtual switch state to Gateway
Serial.println("4"); // Debug code. Print "4" to show that button 4 was pressed
break; // End of code for button 4
case '2': // If the pressed key compares with "2"
VirtalSwitch1 = true; // Change te state of boolean VirtalSwitch1 to true
send(msgV2.set(1)); // sending virtual switch state to Gateway
Serial.println("2"); // Debug code. Print "2" to show that button 2 was pressed
break; // End of code for button 2
case '5': // If the pressed key compares with "5"
VirtalSwitch1 = false; // Change te state of boolean VirtalSwitch1 to false
send(msgV2.set(0)); // sending virtual switch state to Gateway
Serial.println("5"); // Debug code. Print "4" to show that button 5 was pressed
break; // End of code for button 5
case '3': // If the pressed key compares with "3"
VirtalSwitch1 = true; // Change te state of boolean VirtalSwitch1 to true
send(msgV3.set(1)); // sending virtual switch state to Gateway
Serial.println("3"); // Debug code. Print "2" to show that button 2 was pressed
break; // End of code for button 2
case '6': // If the pressed key compares with "6"
VirtalSwitch1 = false; // This doesn´t really make sense here. Key "3" triggers Garden light for 5 Minutes
send(msgV3.set(0)); // Reset this with a switch doesn´t meet the purpose of this switch (3), it (6) may be used for something else.
Serial.println("6"); //
break; // End of code for button 6
// Other keys to be added here according to the same template
default: // If the pressed key does not match the cases above
Serial.println(key); // Print the key that was pressed
break; // End of function
}
}
// ##### WRITE BOOLEAN TO PIN (FOR TESTING PURPOSES ONLY) #####
digitalWrite(IoPin4, VirtalSwitch1);
}
void
presentation() {
present(CHILD_ID_V1, S_LIGHT, "Partylichtjes");
present(CHILD_ID_V2, S_LIGHT, "Verwarmingstoestel");
present(CHILD_ID_V3, S_LIGHT, "Tuinverlichting gedurende 5 min");
present(CHILD_ID_V4, S_LIGHT, "Bewegingsdetector");
present(CHILD_ID_V5, S_LIGHT, "Muziek");
}```@Reza said:
!TSM:READY:UPL FAIL,SNP
I had not got such errors due to power issues. Unstable/insufficient power supply mostly resulted in inconsistent functions - not in steady errors. Sometimes (depending on weather? phase of the moon?) functions were ok, sometimes not.
Changing power supply (either batteries or buck-device) healed this problems.
So far I understand your error-messages they could probably mean what they say:
UPLink control FAILed and your node is Searching New Parent - which is a logical consequence.
I think flopp and Jan Gatzke are right: 50 meters is quite a large distance - may be too much for stable connection.
If your device is mobile - lower the distance (just for testing purposes) and look for a stable connection. Depending on the result you may take further actions like described above or - if you like tinkering - you may have a look at
http://www.instructables.com/id/Enhanced-NRF24L01/ or Cheap DIY NRF24L01 Antenna Modification – 02:48
— Pete B
I have not done this until now - but it looks really cool.
@C.r.a.z.y. OpenHab doesn't offer such methods like "inclusion" or search for unknown devices at the moment. But this is not due to MySensors properties, this is common to all bindings.
Prerequisite for working with OpenHab seems to be the knowledge of your hardware to a very low level (e.g. programming the sensors yourself = MySensors). Accessing the configuration files results in great possibilities but also in much work.
There is another User-Interface to this functions - https://github.com/cdjackson/HABmin - you might give this a try to get rid of the Eclipse-part of the OpenHab designer. I haven't tried it, but the slideshows are really impressive. Habmin may result in easier working -- but probably not in less work.
You haven't told us what project you are aiming for - so it's a bit difficult to give a hint what may fit your needs.
Regarding your last question, consider the following example:
String HomeMaticS1 "Status1-1 [%s]" <shield> (HomeMatic,kitchen, FirstFloor) {homematic="address=JEQ0459986, channel=1, parameter=LED_STATUS" }
It is a String definition for my Homematic controlling one of 16 dual-color LEDs
String denotes the type of this object
HomematicS1 ist the name of this object.
"Status1-1" ist the label displayed in the browser.,** [%s]** is a formating directive.
**<shield> **is the name of the icon (which has to reside in \OpenHab1.6.1\webapps\images\shield.png --with exact this name)
The round parenthesis **(Homematic, kitchen, FirstFloor) **tells Openhab to which group this object belongs --yes, one object may belong to many groups (= frames).
The rest of this declaration implements the homematic binding with parameters you should know before - as mentioned above.
The other 15 LEDControls are simply constructed by copy&paste and changing the numbers accordingly. Inconsistent numbering is a nice pitfall here and provides you with many happy hours.
With the following Frame in the current .sitemap
Frame label="MyFrame" {
Group item=HomeMatic icon="homematic"
Group item=kitchen icon="kitchen"
}
Item **HomematicS1 ** will show up in both subframes labeled as "Status1-1".
This applies to switches and other widgets in the same way, so you can operate your actors from within different frames.
Does sleep stop all code from running, or just the function that its in? In other words; My keypad code is in the loop function. The mysensor code for receiving messages is in another funtion outside the loop function (void receive). Does a sleep in the loop function also blocks void receive, or does it only block the loop part?
Disabling the sleep function (with just a // ) seems to work, but its flooding (debug still enabled off course) the serial monitor "with Failed reading temperature from DHT! Failed reading humidity from DHT
An excerpt of the DHT samplesketch:
// Sleep time between sensor updates (in milliseconds)
// Must be >1000ms for DHT22 and >2000ms for DHT11
static const uint64_t UPDATE_INTERVAL = 60000;
static const uint64_t MEASURING_INTERVAL = 30000;
// Force sending an update of the temperature after n sensor reads, so a controller showing the
// timestamp of the last update doesn't show something like 3 hours in the unlikely case, that
// the value didn't change since;
// i.e. the sensor would force sending an update every MEASURING_INTERVAL*FORCE_UPDATE_N_READS [ms]
static const uint8_t FORCE_UPDATE_N_READS = 10;
Thus your code must result in more than 1 reading per 2 seconds, so the DHT Sensor is not ready and fails.
So as you expected, it boils down to enclose the DHT code into an millis() controlled if-Statement.
Basically it looks like this
static const uint64_t UPDATE_INTERVAL = 60000;
static const uint64_t MEASURING_INTERVAL = 30000;
// before setup() aka global variables
unsigned long last_time = 0, actual_time = 0;
----------
// within loop()
if ( (millis() - last_time) >= MEASURING_INTERVAL) {
last_time = millis();
// Force reading sensor, so it works also after sleep()
dht.readSensor(true);
// rest of your DHT Code here
} // don´t forget closing parenthesis (after Humidity is done)
you will recognize the fragments, they originate form the DHT Example Sketch.
@reza:
I made some modifications to your sketch, trying to adhere to your style of programming. So it may be easier to adapt it to your needs.
#define MY_DEBUG
#define MY_RADIO_NRF24
#define MY_RF24_CHANNEL 0
#define MY_REPEATER_FEATURE
#define MY_NODE_ID 5
#include <SPI.h>
#include <MySensors.h>
#include <Bounce2.h>
#define RELAY_ON 0
#define RELAY_OFF 1
#define A_ID 1
#define B_ID 2
#define C_ID 3
#define D_ID 4
#define E_ID 5
#define F_ID 6
#define DISPLAY_INTERVALL 10000
const int buttonPinA = 14;
const int buttonPinB = 15;
const int buttonPinC = 16;
const int buttonPinD = 17;
const int buttonPinE = 18;
const int buttonPinF = 19;
const int relayPinA = 3;
const int relayPinB = 4;
const int relayPinC = 5;
const int relayPinD = 6;
const int relayPinE = 7;
const int relayPinF = 8;
int oldValueA = 0;
int oldValueB = 0;
int oldValueC = 0;
int oldValueD = 0;
int oldValueE = 0;
int oldValueF = 0;
unsigned long loop_count = 0; // counter for loop activity
unsigned long last_time;
bool toggleA = false, toggleB = false, toggleC = false, toggleD = false, toggleE = false, toggleF = false;
Bounce debouncerA = Bounce();
Bounce debouncerB = Bounce();
Bounce debouncerC = Bounce();
Bounce debouncerD = Bounce();
Bounce debouncerE = Bounce();
Bounce debouncerF = Bounce();
MyMessage msgA(A_ID, V_STATUS);
MyMessage msgB(B_ID, V_STATUS);
MyMessage msgC(C_ID, V_STATUS);
MyMessage msgD(D_ID, V_STATUS);
MyMessage msgE(E_ID, V_STATUS);
MyMessage msgF(F_ID, V_STATUS);
void setup()
{
pinMode(buttonPinA, INPUT_PULLUP);
pinMode(buttonPinB, INPUT_PULLUP);
pinMode(buttonPinC, INPUT_PULLUP);
pinMode(buttonPinD, INPUT_PULLUP);
pinMode(buttonPinE, INPUT_PULLUP);
pinMode(buttonPinF, INPUT_PULLUP);
// After setting up the buttons, setup debouncer
debouncerA.attach(buttonPinA);
debouncerA.interval(5);
debouncerB.attach(buttonPinB);
debouncerB.interval(5);
debouncerC.attach(buttonPinC);
debouncerC.interval(5);
debouncerD.attach(buttonPinD);
debouncerD.interval(5);
debouncerE.attach(buttonPinE);
debouncerE.interval(5);
debouncerF.attach(buttonPinF);
debouncerF.interval(5);
// Make sure relays are off when starting up
digitalWrite(relayPinA, RELAY_OFF);
digitalWrite(relayPinB, RELAY_OFF);
digitalWrite(relayPinC, RELAY_OFF);
digitalWrite(relayPinD, RELAY_OFF);
digitalWrite(relayPinE, RELAY_OFF);
digitalWrite(relayPinF, RELAY_OFF);
// Then set relay pins in output mode
pinMode(relayPinA, OUTPUT);
pinMode(relayPinB, OUTPUT);
pinMode(relayPinC, OUTPUT);
pinMode(relayPinD, OUTPUT);
pinMode(relayPinE, OUTPUT);
pinMode(relayPinF, OUTPUT);
wait(1000); // testing LEDs. should be omitted for Relais.
digitalWrite(relayPinA, RELAY_ON);
digitalWrite(relayPinB, RELAY_ON);
digitalWrite(relayPinC, RELAY_ON);
digitalWrite(relayPinD, RELAY_ON);
digitalWrite(relayPinE, RELAY_ON);
digitalWrite(relayPinF, RELAY_ON);
/*--------------------- Added these lines for toggle switch-------------------------*/
oldValueA = digitalRead(buttonPinA); // set oldValueA to the current status of the toggle switch
oldValueB = digitalRead(buttonPinB); // set oldValueB to the current status of the toggle switch
oldValueC = digitalRead(buttonPinC);
oldValueD = digitalRead(buttonPinD);
oldValueE = digitalRead(buttonPinE);
oldValueF = digitalRead(buttonPinF);
}
void presentation() {
// Send the sketch version information to the gateway and Controller
sendSketchInfo("RELAY6", "0.1");
// Register all sensors to gw (they will be created as child devices)
present(A_ID, S_LIGHT, "Relais A");
present(B_ID, S_LIGHT, "Relais B");
present(C_ID, S_LIGHT, "Relais C");
present(D_ID, S_LIGHT, "Relais D");
present(E_ID, S_LIGHT, "Relais E");
present(F_ID, S_LIGHT, "Relais F");
}
/*
Example on how to asynchronously check for new messages from gw
*/
void loop()
{
loop_count ++; // increment loop count
if ( millis() >= last_time + DISPLAY_INTERVALL ) { // Display Loop-cycles every DISPLAY_INTERVALL milliseconds
last_time = millis(); // reset and start over again
Serial.print("loop_count: ");
Serial.println(loop_count);
loop_count = 0;
}
debouncerA.update();
// Get the update value
int valueA = debouncerA.read();
if (valueA != oldValueA && valueA == 0) {
send(msgA.set(toggleA, true)); // Send new state and request ack back
digitalWrite(relayPinA, toggleA); // switch relais
Serial.println("Switch A pressed");
toggleA = !toggleA; // this is the actual toggle switch
}
oldValueA = valueA;
debouncerB.update();
// Get the update value
int valueB = debouncerB.read();
if (valueB != oldValueB) {
send(msgB.set(valueB ? false : true), true); // Send new state and request ack back
Serial.println("Switch B pressed");
oldValueB = valueB;
}
debouncerC.update();
// Get the update value
int valueC = debouncerC.read();
if (valueC != oldValueC) {
send(msgC.set(valueC ? false : true), true); // Send new state and request ack back
Serial.println("Switch C pressed");
oldValueC = valueC;
}
debouncerD.update();
// Get the update value
int valueD = debouncerD.read();
if (valueD != oldValueD) {
send(msgD.set(valueD ? false : true), true); // Send new state and request ack back
Serial.println("Switch D pressed");
oldValueD = valueD;
}
debouncerE.update();
// Get the update value
int valueE = debouncerE.read();
if (valueE != oldValueE) {
send(msgE.set(valueE ? false : true), true); // Send new state and request ack back
Serial.println("Switch E pressed");
oldValueE = valueE;
}
debouncerF.update();
// Get the update value
int valueF = debouncerF.read();
if (valueF != oldValueF) {
send(msgF.set(valueF ? false : true), true); // Send new state and request ack back
Serial.println("Switch F pressed");
oldValueF = valueF;
}
}
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 1:
digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
break;
case 2:
digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
break;
case 3:
digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
break;
case 4:
digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
break;
case 5:
digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
break;
case 6:
digitalWrite(message.sensor + 2, message.getBool() ? RELAY_ON : RELAY_OFF);
break;
default:
Serial.println("bad message (child_id >6)");
break;
}
// Write some debug info
Serial.print("Incoming change for sensor:");
Serial.print(message.sensor);
Serial.print(" from node:");
Serial.print(message.sender);
Serial.print(", New status: ");
Serial.println(message.getBool());
}
}
I haven`t copied the code for all push-buttons - I leave this to you if this sketch is functional for your needs.
Acting carefully, you may mingle some parts with blacey´s sketch successfully (by the way - impressing coding style).
Reenacting your sketch I found some strange behavior: no reaction to push-button-press - meaning the sketch didn´t even take notice of the push-button after it had been pressed once - or sometimes twice.
Adding an external pull-up resistor (4.7k) fixed this problem.
So maybe it has not been a sending problem but a hardware problem (internal pull-ups to weak?).
Please flood your sketch with print statements - like "button A pressed" "send command issued" etc. and watch your serial terminal carefully and/or post your logs.
Thinking about the modulo-driven time-statement - actually it is a cute idea. Something like
time_m = millis();
a = (time_m / 1000) % 3600;
should make it immune to uneven starting values an even loop-cycle duration. (loop-cycle-time of the above sketch: approximately 125 µs)
These are the lesser problems. I fear you have to do some boring English lecture.
Please read: https://en.wikipedia.org/wiki/Finite-state_machine
https://en.wikipedia.org/wiki/State_machine_replication
and first: https://en.wikipedia.org/wiki/Two_Generals'_Problem
https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
as an excerpt :
The Two Generals Problem was the first computer communication problem to be proved to be unsolvable.
This is not "we don´t have a solution until now" but: "it is sure there can´t be a solution"
So you will have to live with a certain amount of uncertainty .....
Conclusion:
Check correct function of push-button with Serial.print(), with and without external pull-up resistor.
Please post your logs afterwards.
be prepared to make some decisions concerning tolerable fuzziness.
if necessary start learning about scripting capabilities of your controller.
I forgot about the DEBUG part.
<logger name="org.openhab" level="INFO"/>
<logger name="org.openhab.binding.mqtt" level="DEBUG" />
<logger name="org.openhab.io.transport.mqtt" level="DEBUG" />
In File "logback.xml" look for the first line and insert the second and third line.
This will lead to some additional infos in Openhabs output.
I'm looking for some trace of successfully established connections between OpenHab and MQTT broker.
If there is no connection the switch will show like you described above.
@SuperKris
you already solved the problem with Pin0 and 1 (did you?). Here is possibly another solution (from 2.0 API
MY_DISABLED_SERIAL Disabled Enable this in sketch if you want to use TX(1), RX(0) as normal I/O pin
so
#define MY_DISABLED_SERIAL
should free Pin 0 and Pin 1.
@xelnaha
Lazy sunday afternoon -got time to "fix" some problems.
Not being capable of reading EBAY item descriptions properly, I got some Pro Mini 168 waiting for some work to do.
Please be aware what the boss says:
The atmega168 is not officially supported, due to the low flash / ram size, compared to atmega328 (tbowmo, ADMIN, 2 months ago)
So far I remember are the Pro mini 168 essentially clones based upon Arduino Duemilanove just without power supply and USB.
Within file "digitalWriteFast.h" in "<whatever>/Mysensors/drivers/avr/DigitalWriteFast/" at line 69
#elif defined(ARDUINO_AVR_UNO) || defined(ARDUINO_AVR_DUEMILANOVE) || defined(__AVR_ATmega328__) || defined(__AVR_ATmega328P__) || defined(__AVR_ATmega328PB__)
I added
#elif defined(ARDUINO_AVR_UNO) || defined(ARDUINO_AVR_DUEMILANOVE) || defined(__AVR_ATmega328__) || defined(__AVR_ATmega328P__) || defined(__AVR_ATmega328PB__) || defined (__AVR_ATmega168__)
because it is not fair to mention DUEMILANOVE and not to give credits to ATmega168.
With this modification compiling and uploading work well.
Please remember:
tbowmo was (is) right about memory capacity. The "BinarySwitchSensor" example sketch uses 14258 bytes from 14336 maximal Bytes. This is a really tight fit. Stripping debug information results in 7604 bytes.
@Reza
Sometimes it is better to step back and have a look from the distance.
A receipe for a clean restart.
you need:
2 working Arduinos with radio (node 4 and node 3 from your log)
1 working Computer/Laptop with 2 free USB interfaces
preferably Windows with Arduino IDE installed. (Linux might work too.)
connect both arduinos to your USB ports.
if Arduinos are different - write down which Arduino is on which port (eg. com34: or similar)
You are done. Watch Arduinos communicating via serial monitor.
Ok- you are right - it is not truely simultaneaus - but close enough.
If this is ok you should try to upload the relay-sketch and watch what is happening.
This should not take to long, and as a result you will hopefully know:
@Reza I think we are getting close to solution.
but after start or reset , some time relay choose a node (10 m far) for parent, while gateway is near that ! why ?
This seems to be the crucial question.
I never dived into the core functions how MySensors decides about choosing parent.
Maybe it depends upon speed of answer?
a little excerpt from an earlier log (which i didn´t read close enough, I told you).
16 TSM:FPAR
52 TSF:MSG:SEND,4-4-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2059 !TSM:FPAR:NO REPLY
2061 TSM:FPAR
2097 TSF:MSG:SEND,4-4-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2165 TSF:MSG:READ,2-2-4,s=255,c=3,t=8,pt=1,l=1,sg=0:1
2170 TSF:MSG:FPAR OK,ID=2,D=2
2340 TSF:MSG:READ,3-3-4,s=255,c=3,t=8,pt=1,l=1,sg=0:3
4105 TSM:FPAR:OK
4106 TSM:ID
at 2097 Node 4 broadcasts for parent and gets accepted for parenting from Node 2.
at 2340 Node 3 offers parenting too - upon which request?
and why doesn`t GW offer parenting ?? GW shows up at 8240 with response to PING, so it is alive and connection was ok.
at least at the moment - unexpected behavior.
So reading logs give us some hints.
Could you provide a little more from the simultaneous logs? And don´t stick to the NACK logs - the other messages are interesting as well.
Maybe you should give
#define MY_RF24_PA_LEVEL RF24_PA_MIN
a try.
Being short of NRF modules, I ordered 10 pcs from my trusted EBAY-Seller for about 6.5€. What a disappointing experience - none of the modules did its work. All failed with
!TSM:FPAR:NO REPLY
10 defective modules in a row? Not likely. Clones? "Second source"? Fake? - maybe. So back to the roots, digging out maniacbug's library, uploading test sketches (pingpair_ack) - and ... no communication.
Regarding debug output the only difference between working and dysfunctional modules was PA_LEVEL (PA_LOW vs. PA_MAX). So switching to PA_MIN resulted in almost flawless communication arround 5-7m (inhouse with much armoured concrete, not noticeably different from "working" NRF modules).
Reducing PA_LEVEL is advised frequently in this forum, but I never thought of reducing to PA_MIN.
Interesting observation: increasing PA_LEVEL from PA_MIN to PA_LOW resulted in way much higher Round-Trip-Times (6000µs vs 650µs) and some failures (indicating bad transmissions), increasing to PA_LEVEL to PA_HIGH broke communication completely.
So recompiling Mysensors sketches with RF24_PA_MIN did the trick, the probably "fake" modules are doing their job.
@abrasha
Last first: no, I wasn't aiming on current measurement, but it is a really good idea. It would be interesting where does the current come from, and much more interesting where does it go to when you disconnect ground (assuming your circuit is still working without ground connection...)?
Yes, your multimeter should go in series with either VCC or GND.
In the photos above the RFM module doesn't match the module on the breakout board. Please have a look at https://www.sparkfun.com/products/13910 here especially photo 4 (and have photo 3 in mind - it has to be flipped over and it is top down).
I tried to label the photo of the RFM69HCW, but I was kind of dazzled by transposition. Please crosscheck this.
.
But either way - your measurements give already some hints. Assuming you are powering your Arduino from USB - where do 4.55v come from? Backward current through your power regulator? Although 4.55v would be OK for the adafruit board (because power regulator needs only 3.5 V to start operation).
Did you measure Vin (from Arduino) under load? Is it capable of driving this load (i.e. does voltage drop down significantly under load)?
Next hint: why ever - 3.2V are generated on your board. So your power regulator (probably AP2112-3.3) is oK. But measuring at RFM- 3.3V connector (under load) won't hurt.
If labeling is correct, NSS = 1.54v doesn't make much sense - it would indicate a high frequent switching action (to be expected on SCK or MISO/MOSI during data transfer). NSS (CS) shouldn't probably switch at this high rate.
miso shows 0v all the time.
There should be at least a little data on miso , so it should not be 0 all the time.
And just for completeness - please measure voltage at "EN" at your adafruit board. Voltage should be constant 4.XX Volts (should be Vin), if not - module is disabled.
@HogBil
Did you check your "boards.txt"?
Please have a look at
https://forum.mysensors.org/topic/5786/ethernet-gateway-no-lan-traffic-after-initial-controller-setup/2
respectively
https://forum.mysensors.org/topic/5716/solved-w5100-ethernet-gateway-with-nrf24-stable-mysensors-2-1-0-problem/3
Hi @Gad Ofir,
Though I'm not familiar with MySensors and MQTT, this protocol reminds me of my first steps with MySensors when I forgot to assign static IDs for my Nodes and the Controller (e.g. MyController https://www.mycontroller.org/#/home) wasn't up and running. You didn't mention which controller you are using - it should be capable of assigning IDs to nodes.
Copying your sensorlog to the logparser (https://www.mysensors.org/build/parser) shows the lack of an answer to a Request for ID.
I short circuited the whole ID-process by assigning "hard" IDs in the sketch (e.g.
#define MY_NODE_ID 100
This should bypass ID-Requests.
I am not familiar with the exact protocol in the newer MySensors versions so I can't explain the origin of the mentioned ID 237 (???).
In my environment a Node startup looks like:
__ __ ____
| \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| | | | |_| |___| | __/ | | \__ \ _ | | \__ \
|_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/
|___/ 2.3.0
16 MCO:BGN:INIT REPEATER,CP=RNNRA---,VER=2.3.0
26 MCO:BGN:BFR
27 TSM:INIT
28 TSF:WUR:MS=0
35 TSM:INIT:TSP OK
37 TSM:INIT:STATID=4
39 TSF:SID:OK,ID=4
40 TSM:FPAR
77 TSF:MSG:SEND,4-4-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
796 TSF:MSG:READ,0-0-4,s=255,c=3,t=8,pt=1,l=1,sg=0:0
801 TSF:MSG:FPAR OK,ID=0,D=1
871 TSF:MSG:READ,7-7-4,s=255,c=3,t=8,pt=1,l=1,sg=0:1
2084 TSM:FPAR:OK
2085 TSM:ID
2086 TSM:ID:OK
2088 TSM:UPL
2094 TSF:MSG:SEND,4-4-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2110 TSF:MSG:READ,0-0-4,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2115 TSF:MSG:PONG RECV,HP=1
2117 TSM:UPL:OK
2119 TSM:READY:ID=4,PAR=0,DIS=1
so there is no request for ID.
Hi Gad Ofir,
The Node ID is supplied in the Node Sketch, so you have to modify your PIR sketch (slightly) as shown above.
The drawback of "hard" coded IDs is - you have to compile every sketch for every node individually and you have to keep track of the used IDs to avoid conflicts. For me (about 20 Sensors) it is manageable.
About a year ago i tried OpenHab (2.2 I think). There was a kind of plugin for MySensors and it worked very well. So there is a nice way to bypass MQTT.
I didn't continue OpenHab because it was a slight overkill for my purpose in comparison to MyController which does the trick completely. By the way - MyController seems to work with MQTT too, but I haven't tried it (yet).