If you want to use library functions outside the main sketch, you can also just include the core header, e.g.
#include "core/MySensorsCore.h"
If you want to use library functions outside the main sketch, you can also just include the core header, e.g.
#include "core/MySensorsCore.h"
If you use an ISP programmer, you can reprogram the fuses and use it on lower voltages also. Upto 1.8v but also 3.3v
I haven't tested it, but this one seems to fit what you need
https://github.com/mycontroller-org/serial2mqtt/blob/master/README.adoc
@skywatch said in Auto resend on NACK:
@electrik & @Marek - Are you both sure about that? It seems to me that both those statements are doing what was intended.
Now that I see it again, I'm not so sure anymore actually.
In your code you used the variable msg. That should be one of msgFgeHum, msgFgeTemp, msgFzrHum, msgFzrTemp.
That is why the compiler complains msg is unknown.
You also enabled the ack message, this is just a software acknowledge, while the send function returns the status of the hardware acknowledge. So if you check with
if (send(msgFgeHum.set(fgehum),true))
{
// this is sent ok
}
else
{
// sending failed
}
you check if the hardware acknowledge was successful. The software ack should be tested differently and some more logic is needed for it.
Hope this helps
You should move the define for the node ID before you include mysensors.h
Exactly. Better to ask then waste many hours
You can remove these lines, the declaration is already done in the MySensors framework. For presentation() it is needed because you write code there, that is in the function. Now you only call the function, and the code is already in the framework.
I am using the Pinchange interrupts to wake up from sleeping.
Maybe this helps?
See code snippets below.
#include <PinChangeInt.h> //include PinChange lib from MySensors utilities
in setup()
attachPinChangeInterrupt(BotLeft_PIN, BotLeft_ISR, CHANGE);
and in the ISR
void BotLeft_ISR() {
_wokeUpByInterrupt = 0xFE; // work-around to force MS lib to handle this interrupt
// more code here
}
There are many examples...
https://forum.mysensors.org/topic/3764/p1-smart-meter-nta8130-readout-using-mysensors/7
Or on GitHub, needs some tinkering to integrate in mysensors
https://github.com/search?l=C%2B%2B&q=P1+meter&type=Repositories
Edit
There is also a library available
https://github.com/matthijskooijman/arduino-dsmr
@skywatch still if you use wait(), the rest of the code in the loop is not executed during the waiting time. Only the mysensors core is executed
You should do the same for requestTime();
Hello
I've tried to use this with an ESP32 (I modified some defines for the architecture, to make it compatible). In MyHwESP32.h I've changed
#define MY_SERIALDEVICE Serial
to
#ifndef MY_SERIALDEVICE
#define MY_SERIALDEVICE Serial
#endif
I think this why it doesn't work for you @ricorico94 with version 2.3 of MySensors.
It worked sometimes, but usually Putty responds "Network error: Connection refused"
Any ideas?
MY_DISABLED_SERIAL wil output nothing on the serial, no matter software or hardware serial. So in your case you don't need to define it.
And try removing the semicolon after
#define MY_DEBUGDEVICE mySerial;
@mfalkvidd said in Strange behavior on MQTT Gateway Reset:
MySensors does set the retain message on I_BATTERY_LEVEL messages (but no other messages)
If the define MY_MQTT_CLIENT_PUBLISH_RETAIN is used, all messages are retained. But that is not active by default, so probably not used in this case. Just to be complete
You can also try to use esp32 board definition v1.0.0. I guess you are now using 1.0.1
@linkinpio in the pubsubclient library, you can change the timeout on connecting to the mqtt broker. Default it is 15s, reducing it to e.g. 2s will increase the availability of the main loop.
Here the picture of the assembled board. The top board is a temperature sensor so not necessarily needed.
I'm not using a wired connection, but had many connection issues also. It took long time before the gateway was up, MQTT connections dropped.
Then I replaced my router (the one delivered by the cable supplier) and I have no issues anymore. So that could be worth a try.
Look here for a working example with nrf24:
@alowhum said in Easiest way to enable/disable MySensors on running node?:
I could create a lot of if (connecting_allowed){ around the send()functions in the script. But perhaps there's an easier way that involves less coding?
Make a new sendWithPermission()
function that is called from the sketch, and check in there if (connecting_allowed)
@njwyborn are you sure the board is not responding? Perhaps the message is never delivered due to connection issues? What type of transceiver are you using?
Have a look at the bme280. Low power and low voltage and starts at -40 °C
https://www.bosch-sensortec.com/products/environmental-sensors/humidity-sensors-bme280/
It is available on Aliexpress also
This line
send(msgFgeHum.set(fgehum),true)
Should be
if (send(msgFgeHum.set(fgehum) == true)
This is an interesting find, can you share the link? I can't find these low prices anywhere.
No I didn't try that, just out of experience.
But now I see you include Mysensors.h again in the example. If you want to use mysensors functions in the header file you should just include
#include <core/MySensorsCore.h>
See also https://forum.mysensors.org/topic/6646/solved-multiple-source-files-including-mysensors-h-problem/2
@alowhum said in Auto resend on NACK:
Hardware ACK is just that is reaches the next node in the network, right? It could be a repeater saying "I got something from you". It doesn't 100% guarantee that it reached the controller correctly.
Yes exactly
@alowhum said in Auto resend on NACK:
Software ACK is the controller sending back the exact same message you sent, but this time with the ACK bit set to true? It goes up and down your entire network. It's the best way to be sure that the message reached the controller, since you could theoretically even check if the message details are still the same as when you sent it.
Yes
@alowhum said in Auto resend on NACK:
Both will happen when you set ACK to true in your send() function?
Yes correct again
@alowhum said in Auto resend on NACK:
Is this a correct summary?
I didn't use the software ack myself but I think this last point is also correct.
If you use saveState() and loadState() the library will handle this for you
@kiesel the pro Mini is the same chip as an Arduino nano, so the speed will be the same for both
You will get multiple messages, if the message arrives correctly but the hardware ACK doesn't.
Do you have a repeater in between the sender and gateway? It could be that the repeater does receive the initial message (and the sensor gets a hardware ACK), but that never reaches the gateway because of a transmission error between the repeater and the gateway.
@dbemowsk You can also use google and add mysensors before the search phrase
No just the Rx, TX and power should be enough.
Interesting finding!
I'm trying to replicate the behaviour, and have added some debug print statements in my code, which shows the tx level after each transmission. The number is changing often which doesn't correspond with your behaviour.
How did you measure this?
If this is desired, the most transparent way would be to implement this function in the controller. You can request a software echo, and if you don't get that, you can send the message again
Like @mfalkvidd said, if you use the new driver, you have to use it on all of the nodes and the gateway, as it doesn't work together with the old one.
You said your code is a mess, maybe it is better to step back and use examples for both the node and the gateway and start from there. If that is working you can add your code. Just to exclude something is overlooked.
@jocke4u said in Migrating from openHAB to Home Assistant:
But get in logs a lot of:
2020-05-26 17:32:30 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:32:40 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-26 17:32:50 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:33:10 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:33:30 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:33:39 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-26 17:33:50 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:34:10 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:34:13 WARNING (MainThread) [mysensors] Node 3 is unknown
2020-05-26 17:34:13 WARNING (MainThread) [mysensors] Node 3 is unknown
2020-05-26 17:34:14 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-26 17:34:30 WARNING (MainThread) [mysensors] Node 49 is unknown
2020-05-26 17:34:33 WARNING (MainThread) [mysensors] Node 4 is unknown
These are caused by the nodes not correctly being presented to home assistant.
Check https://www.home-assistant.io/integrations/sensor.mysensors/ for some examples of what the sketch should do so it is recognised by home assistant.
Mainly presenting the sensors and sending a value to the controller.
@karlheinz2000 said in Handling NACKs:
I use NFR24 and RFM69. Behavior is sometimes strange. No NACKs for weeks and then a really high number of NACKs for a few days. Setup not changed. I have no idea why... Same for indoor and outdoor sensors.
I've had similar effects and could relate this back to the gateway. I'm using an MQTT gateway and if that has Wifi connection issues, it is trying to reconnect to the network in a loop. During these retries it can't handle the NRF communication, if there are more messages than fit in the buffer.
After solving these Wifi issues (updated the ESP32 core) and using the latest Mysensors release, things work much better.
I believe this delay is caused by requesting the IP address from your DHCP server. This request has a timeout and the framework waits for this timeout to be completed before continuing with the rest of the code.
Maybe you could try a static IP address instead of DHCP?
To me the errors look like you have connected the gateway to your home assistant controller, and that home assistant is configured for a serial gateway.
Home assistant is processing the debug output as the data it is expecting.
I think you should check your configuration
@alowhum said in Expanding the size of an existing array?:
It's all a one-file sketch.
Even it is only one file, the file can be included from other locations also. So is this #include <SoftwareSerial.h>
also in other files inside your project?
you can also check it by adding this before your define. If the compiler gives an error, this define is used somewhere already.
#ifdef _SS_MAX_RX_BUFF
#error "_SS_MAX_RX_BUFF defined already"
#endif
So, I have added a check in the PubSubclient to work around this. Until now it works quite well and when an invalid packet is received this is not handled.
However, now sometimes the gateway just hangs at some point.
(za 29-08 13:06:53.126) IH<CR>
(za 29-08 13:06:59.846) MQTTP topic
(za 29-08 13:06:59.846) ms-rfm-to/31/2/2/0/3<CR>
(za 29-08 13:06:59.960) 71554750 GWT:IMQ:TOPIC=ms-rfm-to/31/2/2/0/3, MSG RECEIVED
(za 29-08 13:06:59.960) 71554758 THA:SND:MSG=00001F120203023237
(za 29-08 13:06:59.960) IC<CR>
(za 29-08 13:06:59.960) IH<CR>
(za 29-08 13:06:59.960) IC<CR>
(za 29-08 13:06:59.960) IH<CR>
(za 29-08 13:06:59.960) 71554775 THA:SND:MSG LEN=9,RES=1
(za 29-08 13:06:59.960) 71554779 TSF:MSG:SEND,0-0-31-31,s=2,c=2,t=3,pt=0,l=2,sg=0,ft=0,st=OK:27
And then nothing happens.
(The IC and IH are added by me to check on the interrupts, IC is interrupt clear and IH interrupt handle). I've switched on the internal LED on RFM69 interrupt and that is on when this occurs. It is not clear for me if this happens before or after the freeze.
Now I've added the debug defines below, to get more information on what's happening before the freeze. But after this change the software is running for 47h already. So I suspect there could be some timing issue but not sure if, where and how.
#define MY_DEBUG_VERBOSE_RFM69
#define MY_DEBUG_VERBOSE_TRANSPORT_HAL
#define MY_DEBUG_VERBOSE_RFM69_REGISTERS
@keithellis flashing onto an esp8266 is still possible, but you have to make sure you use an earlier esp8266 package, below 3.0 IIRC.
Compiling mysensors will give you an error probably, search on it in the forum and you will find more people with the same issue. And how to solve it
I think - am not sure - because you only include mysensors.h, which is only a header file without cpp files.
@ejlane
My configuration is this, and that seems to work correctly:
mysensors:
gateways:
- device: mqtt
persistence_file: '/config/mysensors-mqtt.json'
topic_in_prefix: 'mygateway1-out'
topic_out_prefix: 'mygateway1-in'
- device: mqtt
persistence_file: '/config/mysensors-rfm-mqtt.json'
topic_in_prefix: 'ms-rfm-from'
topic_out_prefix: 'ms-rfm-to'
optimistic: false
persistence: true
retain: false
version: '2.3'
What exactly doesn't work in your case, and can you post your configuration?
With the latest MySensors integration this is how to delete entities:
Hope it helps someone!
The modules correspond to what it should be.
It looks like your ground is connected to the ANT pin on the picture, on the bottom side of the PCB?
Is it really needed to edit this entity?
If you add it to your dashboard, you should be able to use it.
On the top right click on the three dots, then edit dashboard. Create a card and add the sensor there and you should be good to go!
In https://github.com/mysensors/MySensors/blob/master/core/MyMessage.h#L135
S_RAIN is used. As prefix I guess you can use whatever you want, eg mm/h
@BearWithBeard
Great explanation, thanks!
On my windows 10 installation I had to run Zadig to make the programming from platformIO work.
Are you using the new driver on the gateway also?
I'm doing a similar thing, but use node red to inject the values directly to mqtt. This brings more flexibility as it allows any value to be injected, while home assistant checks on values as they are defined in the mysensors protocol specification.
@BearWithBeard Thanks that did it.
Could it be the TX and RX are switched on the BMP in your post?
This is a good tip to add to the build instructions. Check if you plugged the cable
@harrdy You don't have to use a stepdown board, you can just use a resistor divider to lower the voltage.
With one diode you will still not have a DC signal yet, better to use two diodes or a bridge rectifier. After the rectifier place a capacitor and the resistor divider.
@briseis I would just switch back to 2.3.2
I also believe 2.4 on the gateway should work with nodes on 2.3.2. what kind of errors did you get when doing this?
Yes, the serial communication is bidirectional for sure. I wasn't sure how sharing of the serial port is done between the in and out node.
Since you receive data (right?) the sketch you have used should be all right.
I have two doubts. The wait statement, could it be this prevents the data from being received?
Second is there should be a newline at the end of the payload as send by the mysencode node.
I'm using the node red also, though with a mqtt gateway.
Edit: how did you deactivate the node? The right way is to delete it.
@stkilda you can already gain quite some power saving if you take off the led and sleep the node, activate it when there is something to do.
Yes, but now use the 2.3.2 release with this modification
@Alberto77 said in Beginner receive() question:
Yes I also tried with different characters added at the end (no character, \r, \n ) all tested, no effect.
The right one is to add '\n'.
The next try would be to connect the serial gateway to a pc and enable MY_DEBUG on the gateway. Maybe this tells you more.
@kted The chip can work on different frequencies, but the discrete parts and the antenna are tuned for this frequency.
As the frequencies you want to try are quite close, the discrete parts are the same and changing the frequency is a matter of settings in the chip. So a different sketch. And perhaps cut your antenna a bit.
And if you change the lines like below now?
@smilvert said in GWT:TPC:CONNECTING:
it dosen't. But when I changed the delay to 3000
bool gatewayTransportConnect(void)
{
#if defined(MY_GATEWAY_ESP8266) || defined(MY_GATEWAY_ESP32)
if (WiFi.status() != WL_CONNECTED) {
GATEWAY_DEBUG(PSTR("GWT:TPC:CONNECTING...\n"));
delay(3000); // Was 1000
return false;
}
GATEWAY_DEBUG(PSTR("GWT:TPC:IP=%s\n"), WiFi.localIP().toString().c_str());in MyGatewayTransportMQTTClient.cpp then it started to work!
In Home Assistant you have the Node Red configuration (under supervisor). There you can add packages to be installed under system_packages: []
@david-d Andreas Spiess made a nice video for this, I think this is a good place to start:
#383 Cheap and simple Solar Power for our small Projects (ESP32, ESP8266, Arduino) – 14:11
— Andreas Spiess
That should be okay. Maybe use the mysensors stable release 2.3.2?
Yes I have home assistant but don't have the build essentials. I did some more reading and it seems like a package of build tools. Perhaps @tbowmo knows which specific one is needed?
Good to hear! Perhaps a GitHub issue should be raised for these points...
Can you post your node and gateway sketch?
I think you should start with an example sketch, e.g. you don't need the heltec defines I recall.
I've had similar issues, which in the end was caused by too little memory.
What's is the memory usage saying? All these print statements require a lot of memory.
A good start would be to post the sketch
A simple solution would be to weigh the condensate, but I'm not sure whether this is possible (from a mechanical point of view)
Shouldn't this define
#define MY_RFM95_IRQ_NUM MY_RFM95_IRQ_PIN
Be
#define MY_RFM95_IRQ_NUM digitalPinToInterrupt(MY_RFM95_IRQ_PIN)
Now the interrupt isn't handled and the received message isn't noticed.
Mysensors is a protocol on its own, so it will not decode your doorbell signal.
An Arduino nano can't be reached over SSH no, the Arduino has a usb connection which gives out serial data to the raspberry
You have a delay(10000); in the loop() function. To start I would comment that out and see if the issue is solved.
During the delay() nothing can be done. You should use the millis() function to perform time based tasks, that won't block the loop.
Have you connected the interrupt pin on the node?
And perhaps tried without the new driver? I don't know how that works with a RPI, does it have an old driver also?
Yes, comment
#define MY_DEBUG
and in setup() add
Serial.begin(115200);
There are two drivers on the RFM69 which aren't compatible. Check if you are using the same one on nodes and gateway.
MY_RFM69_NEW_DRIVER
Also the radio settings have to match.
https://www.mysensors.org/apidocs/group__RFM69SettingGrpPub.html