💬 Relay

bjacobse

Retail solution is not the keyword here. What I am searching for is an authorized/lawful (safe) solution.

Sorry to comment negative, but your wording doesn't make sense. either you will go for a DIY solution, cheap and illegal (but not necessary a bad solution), or you will purchase a retail solution.
Retail solution must have the required certificates to allow you to sell. Those are not cheap to get, which also provide the reason for a retail solution to
be usually fairly expensive
https://arbejdstilsynet.dk/da/regler/bekendtgorelser/i/sam-indretning-af-tekniske-hjaelpemidler-612

And also you need Notified Body
https://en.wikipedia.org/wiki/Notified_Body

And I know that Cetekom can create certificate for Country Approvals
https://www.cetecom.com/en/certification/country-appoval/

slt1

There is a problem with the example code for RelayActuator.ino It is not checking for ACK messages. See the other example called SecureActuator.ino that does this. Without checking for ACK messages my relay gets an ON signal and turns on then immediately thereafter gets an ACK signal for V_STATUS command which is assumed in this example to be a control and the value is "0" so it turns off the relay.

mfalkvidd

@slt1 I'm not sure I'm following. RelayActuator.ino does not send any messages, so it should never receive any ack messages. Compare with RelayWithButtonActuator.ino which does send messages, and therefore also checks for ack.

Could you elaborate on the problem?

slt1

@mfalkvidd

For some reason I am now unable to reproduce the issue on the standard RelayActuator.ino example. It was definitely sending ACK requests when I was testing a few days ago. I have subsequently updated MySensors library and also MyController to their latest Snapshot - so perhaps the issue comes up under one of those scenarios.

The issue around this though is that the example does not report the current status of the relay in the loop. My own sketch was doing so. I guess many people take an example and modify it like I do. Therefore copying the example and adding in the code to send the current relay status periodically means the receive function will not work properly due to the Ack messages received,

I would then suggest adding a note to the receive function of the relay example sketch to say that "if your node sends messages then you need to check for Ack and discard those messages" - or something along those lines. This will help !

mfalkvidd

@slt1 thanks for explaining.

I'll think about it for a bit but I hope to submit a pull request soon. I'll post here when it is ready.

mfalkvidd

@slt1 sending current status won't generate an ack/echo message. So there should not be a need to handle the ack/echo flag. Hardware acks (which are enabled by default) do not trigger the receive function.

The only case when an ack/echo message will be sent is if the sketch developer explicitly requests an ack/echo by setting the ack parameter in send() to true. If the sketch developer does that, they need to handle the ack/echo message inside the receive function, according to however they plan to handle the ack/echo message.

My guess is that people set the ack flag to true without understanding what they are doing. I hope to make the documentation slightly less confusing by doing https://github.com/mysensors/MySensors/issues/1103

slt1

@mfalkvidd Thanks - and yes - I did make the assumption that send with ack = true means do a hardware ack. I was unaware that a "software ack" also exists. I read your comment here : https://forum.mysensors.org/topic/3346/discussion-reliable-delivery/17 and what you mention there needs to be made loud and clear in the docs - perhaps some mention in both the message send function and message receive function,

mfalkvidd

@slt1 I agree. Made the same mistake and it took me 40 hours of reading documentation and troubleshooting before I realized there was a difference between the two acks.

b0wi

The script for 'Example with button' works perfectly! Thanks for that.
Has someone a script for multiple Relays with buttons ready to use for me?
I want to use it in my garden to switch the lights with physical buttons and also control them with Domoticz.

jimmy loyens

This post is deleted!

badmannen

I am having this particular switch to be recognized in "Mozilla WEBTHINGS".

IS there some issue with having a repeater node and sensors/switches etc attaches to it? .. it sends in the data as it should when I check with MYSController and I can switch it from there with sending "V_STATUS" messages. but no luck so far of getting the sensors appear in WEBTHINGS , every other sensor works fine.

Seawolf

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enables and select radio type (if attached)
#define MY_RADIO_RF24
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95

#define MY_GATEWAY_ESP8266

#define MY_WIFI_SSID "SSID"
#define MY_WIFI_PASSWORD "PSW"

// Enable UDP communication
//#define MY_USE_UDP // If using UDP you need to set MY_CONTROLLER_IP_ADDRESS or MY_CONTROLLER_URL_ADDRESS below

// Set the hostname for the WiFi Client. This is the hostname
// it will pass to the DHCP server if not static.
#define MY_HOSTNAME "ESP8266_GW"

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
//#define MY_IP_ADDRESS 192,168,0,0

// If using static ip you can define Gateway and Subnet address as well
//#define MY_IP_GATEWAY_ADDRESS 192,168,178,1
//#define MY_IP_SUBNET_ADDRESS 255,255,255,0

// The port to keep open on node server mode
#define MY_PORT 5003

// How many clients should be able to connect to this gateway (default 1)
#define MY_GATEWAY_MAX_CLIENTS 2

// Controller ip address. Enables client mode (default is "server" mode).
// Also enable this if MY_USE_UDP is used and you want sensor data sent somewhere.
//#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 68
//#define MY_CONTROLLER_URL_ADDRESS "my.controller.org"

// Enable inclusion mode
//#define MY_INCLUSION_MODE_FEATURE

// Enable Inclusion mode button on gateway
//#define MY_INCLUSION_BUTTON_FEATURE
// 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 D1

// Set blinking period
//#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Flash leds on rx/tx/err
// Led pins used if blinking feature is enabled above
//#define MY_DEFAULT_ERR_LED_PIN 16 // Error led pin
//#define MY_DEFAULT_RX_LED_PIN 16 // Receive led pin
//#define MY_DEFAULT_TX_LED_PIN 16 // the PCB, on board LED
#define LWIP_OPEN_SRC whatever
#define TCP_MSS whatever
#define LWIP_IPV6 whatever
#define LWIP_FEATURES whatever

#include <MySensors.h>
#include <SPI.h>
//DHT with autodetection

#include <dhtnew.h>

DHTNEW mySensor(5); // ESP 16 UNO 6

uint32_t count = 0;
uint32_t start, stop;

uint32_t errors[10] = { 0,0, 0,0, 0,0, 0,0, 0,0 };

//Domoticz
#define CHILD_ID_HUM 2
#define CHILD_ID_TEMP 3
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);

void presentation()
{
// Send the sketch version information to the gateway
sendSketchInfo("TemperatureAndHumidity", "1.1");

// Register all sensors to gw (they will be created as child devices)
present(CHILD_ID_HUM, S_HUM);
present(CHILD_ID_TEMP, S_TEMP);

}

void setup()
{
Serial.begin(115200);
Serial.println("DHT_endless.ino");
Serial.print("LIBRARY VERSION: ");
Serial.println(DHTNEW_LIB_VERSION);
Serial.println();
}

void loop()
{
count++;
// show counters for OK and errors.
if (count % 50 == 0)
{
Serial.println();
Serial.println("OK \tCRC \tTOA \tTOB \tTOC \tTOD \tSNR \tBS \tUNK");
for (uint8_t i = 0; i < 9; i++)
{
Serial.print(errors[i]);
Serial.print('\t');
}
Serial.println();
Serial.println();
}

if (count % 10 == 0)
{
Serial.println();
Serial.println("TIM\tCNT\tSTAT\tHUMI\tTEMP\tTIME\tTYPE");
}
Serial.print(millis());
Serial.print("\t");
Serial.print(count);
Serial.print("\t");

start = micros();
int chk = mySensor.read();
stop = micros();

switch (chk)
{
case DHTLIB_OK:
Serial.print("OK,\t");
errors[0]++;
break;
case DHTLIB_ERROR_CHECKSUM:
Serial.print("CRC,\t");
errors[1]++;
break;
case DHTLIB_ERROR_TIMEOUT_A:
Serial.print("TOA,\t");
errors[2]++;
break;
case DHTLIB_ERROR_TIMEOUT_B:
Serial.print("TOB,\t");
errors[3]++;
break;
case DHTLIB_ERROR_TIMEOUT_C:
Serial.print("TOC,\t");
errors[4]++;
break;
case DHTLIB_ERROR_TIMEOUT_D:
Serial.print("TOD,\t");
errors[5]++;
break;
case DHTLIB_ERROR_SENSOR_NOT_READY:
Serial.print("SNR,\t");
errors[6]++;
break;
case DHTLIB_ERROR_BIT_SHIFT:
Serial.print("BS,\t");
errors[7]++;
break;
default:
Serial.print("U");
Serial.print(chk);
Serial.print(",\t");
errors[8]++;
break;
}
// DISPLAY DATA
#ifdef MY_DEBUG
Serial.print(mySensor.getHumidity(), 1);
Serial.print(",\t");
Serial.print(mySensor.getTemperature(), 1);
Serial.print(",\t");
Serial.print(stop - start);
Serial.print(",\t");
Serial.println(mySensor.getType());
#endif

//send to gateway
float humidity = mySensor.getHumidity();
send(msgHum.set(humidity, 1));
float temperature = mySensor.getTemperature();
send(msgTemp.set(temperature, 1));

delay(3000);
}

// -- END OF FILE --

Seawolf

I was so happy to have finaly a fonctionnal sketch for my esp8266 gateway whith the DHT22 that i post directly my code.
I hope that it will help some people.
based on: https://github.com/RobTillaart/DHTNew/blob/master/examples/dhtnew_endless/dhtnew_endless.ino

joaoabs

Hi,
Trying to go deep on the API and come this this doubt: The second example (with button) the child seems to be declared as "S_LIGHT" and the receiving messages are "V_LIGHT", while the first example seems better suitable for a relay (child as "S_BINNARY" and requests as "V_STATUS").
I haven't found any "S_LIGHT" or "V_LIGHT" in the API, only "S_LIGHT_LEVEL" and "V_LIGHT_LEVEL". What is the most suitable type for a relay node with a local button?

skywatch

@joaoabs A realy usually has only 2 states, on and off. So I would use S-BINARY and V_STATUS every time.

A changeover realy also has 2 states so again I would go for binary and status.

Light_Level is more suited to getting light levels from a sensor or sending a light level to a dimmable light.

TheoL

Not sure if it ever has mentioned before, but the first example contains

// Enable and select radio type attached
#define MY_RADIO_RF24

Which results in a compile error

MySensors.h:287:4: error: #error No forward link or gateway feature activated. This means nowhere to send messages! Pretty pointless.
   #error No forward link or gateway feature activated. This means nowhere to send messages! Pretty pointless.

It should be:

// Enable and select radio type attached
#define MY_RADIO_NRF24

And then it compiles and works :)

mfalkvidd

@TheoL which version of MySensors are you using when compiling?

The change from NRF24 to RF24 was intentional.

https://github.com/mysensors/MySensorsArduinoExamples/commit/36bee0b7426cc3955d23b3f4918da64fd2cc49ad#diff-1252bb46b9b35d77138b7fd96c37e4d3efa629af89ac0d1c2302cde6cf755ea4

Documentation: https://www.mysensors.org/apidocs/group__RF24SettingGrpPub.html#gad9d7b3f6173e32fa96468e05b901acba

TheoL

@mfalkvidd I'm in an older version I discovered. Ran across more small differences.

skywatch

@TheoL Sound like a good time to update to the latest version. it is the best yet and very stable.

💬 Relay

14

11.7k

11.2k

113.0k