RFLink with NodeMCU, readings are not sent on wifi

Message

955 · #1 Post by **955** » 06 Mar 2020, 22:25

I am using RFLink but as I wanted to go wireless, I am using it with the NodeMCU kit as sold by nodo-shop.nl
The kit connects the RX/TX on the Mega to the TX/RX of the NodeMCU. As per their guide: https://www.nodo-shop.nl/nl/index.php?c ... achment=31
My idea is to create MQTT messages by using the "espRFLinkMQTT" by seb821 on the NodeMCU.
https://github.com/seb821/espRFLinkMQTT

When connected through the USB/serial port RFLink collects measurements from sensors and switches perfectly.
However, when using NodeMCU with wifi and 'espRFLinkMQTT', only ~20% of all RFLink readings are resulting in a MQTT message.

I have used seb821's guide pretty much straight off. Program builds and executes but something seems to go wrong during execution.
seb821 have suggested that some of the latest libs that should not be used?

Anyone have any idea how to resolve and/or debug?

Thanks!

/Niklas

seb82 · #2 Post by **seb82** » 07 Mar 2020, 18:26

Well this is weird. Especially if it working time to time. Did you try disabling the serial debug ? Maybe it will help releasing some processing time.

For information, I have compiled the firmware recently with core 2.6.3 and latest libraries (except Arduinojson that is 5.13.5) and used it with no problems.

What I suspect though it that Wifi is interfering with a good reception of the 433 MHz messages.

955 · #3 Post by **955** » 09 Mar 2020, 22:28

Thanks for replying.
Yes, I think it weird that it is working soso. I would rather accept that it does not work at all.
I am new to the 8266, ESPeasy and Arduino environment but decent in programming.

I am using your code from github, straight off more or less, but had to do a minor change to get it compiling with the RX/TX pin setup.

I am using the following part of config.h:

Code: Select all

/*********************************************************************************
 * Serial and hardware configuration
/*********************************************************************************/
//SoftwareSerial softSerial(4, 2, false,BUFFER_SIZE+2); 
auto& debugSerialTX = Serial;
auto& rflinkSerialRX = Serial;
auto& rflinkSerialTX = Serial;
//SoftwareSerial& rflinkSerialTX = softSerial;

#define MEGA_RESET_PIN 0
//#define SERIAL_DEBUG

It is not possible to uncomment the

Code: Select all

//#define SERIAL_DEBUG

as this will result in a compile error:
espRFLinkMQTT:194:5: error: expected ';' before 'else'
It does look OK too me and I havn't dug further - so SERIAL_DEBUG is undefined.

I also notice that I quite often cannot connect to it using its ipadress. Most of the time webbrowser states that the response takes too long time. And when I am connected it feels unstable and becomes unresponsive after a while. It is just a meter from my router so signal is (too?) strong.
How can 433MHz interfere so severly with a 2.4GHz device?

I tried to crank up the CPU frequency from 80MHz to 160MHz, though I saw a minor improvement but not the silverbullet.
I am compiling with the Board "NodeMCU 1.0" setting.

Happy to get any advice or directions.

Thanks!

/Niklas

seb82 · #4 Post by **seb82** » 10 Mar 2020, 12:08

I have just pushed my latest version to github.
- Default configuration is now using RX/TX ESP pins
- It does compile properly now while uncommenting SERIAL_DEBUG but I could not test functionnality
- There are a few improvements by not using Strings anymore except for web interface

I did figure out that web interface is quite instable. It may be linked to the extensive use of Strings. Unfortunately, my programming skills are not good enough to improve it.

I would not be suprised that there are interferences with wifi as wifi signal is pretty strong and components quite close one to another. You should be able to test it connecting RFLink to your computer and then bringing the ESP close to the RFLink (you may have to do some kind of ping or refresh the web interface in order to generate traffic with the ESP).

955 · #5 Post by **955** » 10 Mar 2020, 22:17

Thanks!
I will get new copy from github and let you know my findings.
Any version restrictions from include libs?

seb82 · #6 Post by **seb82** » 11 Mar 2020, 16:07

955 wrote: ↑10 Mar 2020, 22:17 Any version restrictions from include libs?

Not really except for Arduinojson as mentionned above.

955 · #7 Post by **955** » 12 Mar 2020, 23:17

Some testresults. The changes you have done shows significant improvements on the webpart.
I am, more often able to connect successfully thru the IP adress, and when shown it seems more stable.
Every now and then I still get a timeout but all in all it is a significant improvement.

However, the RFLink+NodeMCU combo does still not pick up all 433MHz sensor readings.
The following log was taken during 5min using the RFLink uploader without NodeMCU, showing the picked up readings on the serial port.

20;00;Nodo RadioFrequencyLink - RFLink Gateway V1.1 - R48;
10;version;
20;01;VER=1.1;REV=48;BUILD=04;
10;status;
20;02;STATUS;setRF433=ON;setNodoNRF=OFF;setMilight=OFF;setLivingColors=OFF;setAnsluta=OFF;setGPIO=OFF;setBLE=OFF;setMysensors=OFF;
2020-03-12 22:43:15 - 20;03;FineOffset;ID=00b7;TEMP=00d8;HUM=38;
2020-03-12 22:43:25 - 20;04;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK;
2020-03-12 22:43:28 - 20;05;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK;
2020-03-12 22:43:35 - 20;06;Cresta;ID=2F01;TEMP=00d6;HUM=39;BAT=OK;
2020-03-12 22:44:03 - 20;07;FineOffset;ID=00b7;TEMP=00d8;HUM=38;
2020-03-12 22:44:08 - 20;08;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK;
2020-03-12 22:44:11 - 20;09;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK;
2020-03-12 22:44:18 - 20;0A;Cresta;ID=2F01;TEMP=00d6;HUM=39;BAT=OK;
2020-03-12 22:44:51 - 20;0B;FineOffset;ID=00b7;TEMP=00d8;HUM=38;
20;0C;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK;
2020-03-12 22:44:54 - 20;0D;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK;
2020-03-12 22:45:01 - 20;0E;Drayton;ID=d290;SWITCH=18;CMD=OFF;
20;0F;Cresta;ID=2F01;TEMP=00d6;HUM=39;BAT=OK;
2020-03-12 22:45:34 - 20;10;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK;
2020-03-12 22:45:37 - 20;11;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK;
2020-03-12 22:45:39 - 20;12;AlectoV3;ID=30b7;TEMP=80b8;HUM=38;BAT=OK;
2020-03-12 22:45:44 - 20;13;Cresta;ID=2F01;TEMP=00d6;HUM=39;BAT=OK;
2020-03-12 22:46:17 - 20;14;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK;
2020-03-12 22:46:20 - 20;15;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK;
2020-03-12 22:46:27 - 20;16;Cresta;ID=2F01;TEMP=00d6;HUM=39;BAT=OK;
2020-03-12 22:47:00 - 20;17;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK;
2020-03-12 22:47:03 - 20;18;Cresta;ID=2801;TEMP=00cb;HUM=57;BAT=OK;
2020-03-12 22:47:10 - 20;19;Cresta;ID=2F01;TEMP=00d6;HUM=39;BAT=OK;
2020-03-12 22:47:15 - 20;1A;AlectoV3;ID=30b7;TEMP=80b8;HUM=38;BAT=OK;
2020-03-12 22:47:43 - 20;1B;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK;
2020-03-12 22:47:46 - 20;1C;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK;
2020-03-12 22:47:53 - 20;1D;Cresta;ID=3901;TEMP=00bc;HUM=64;BAT=OK;
20;1E;Cresta;ID=2F01;TEMP=00d6;HUM=39;BAT=OK;
2020-03-12 22:48:03 - 20;1F;FineOffset;ID=00b7;TEMP=00d8;HUM=38;
2020-03-12 22:48:26 - 20;20;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK;
2020-03-12 22:48:29 - 20;21;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK;
2020-03-12 22:48:36 - 20;22;Cresta;ID=3901;TEMP=00bc;HUM=64;BAT=OK;

But when I use RFLink + nodeMCU I get the following. (using same physical location)
As you can see there are five! sensor readings in ~45min! For sensorID=2101 there are 30min between two readings.
So the majority of readings and other sensors are not reported at all.
Specfically sensorID=2101 comes every ~40sec

I expected the same number of sensor readings using RFLink + nodeMCU.
Why are these not picked up by the RFLink+nodeMCU combo?
Any ideas? How can I debug?

: v2_80MHz_nodeMCU_3.JPG (214.02 KiB) Viewed 117020 times

Stuntteam · #8 Post by **Stuntteam** » 13 Mar 2020, 00:48

Perhaps a lot of resets..?

seb82 · #9 Post by **seb82** » 13 Mar 2020, 14:14

Stuntteam wrote: ↑13 Mar 2020, 00:48 Perhaps a lot of resets..?

This is likely. Indeed, the firmware sends two commands to RFLink at startup : 10;ping; and 10;version;

Code: Select all

rflinkSerialTX.println(F("10;ping;"));                       	// Do a PING on startup
delay(100);
rflinkSerialTX.println(F("10;version;"));                   	// Ask version to RFLink

Did you wire the reset pin from the ESP to RFLink reset pin ?
You can change it with MEGA_RESET_PIN in config.h.

Also, what power supply are you using ? Indeed, an ESP use quite some power and maybe if affects the RFLInk.

seb82 · #10 Post by **seb82** » 13 Mar 2020, 14:25

In fact, it looks like the ESP is resetting, not the RFLInk as it does not start back at zero (hex number after 20;).

My suggestion is to disconnect the RFLink and connect the ESP with USB. Then with the serial monitor, try to send commands from the computer to ESP that are similar to what RFLink sends and see how it reacts. Enabling SERIAL_DEBUG in config.h will bring more information.

Stuntteam · #11 Post by **Stuntteam** » 13 Mar 2020, 17:26

seb82 wrote: ↑13 Mar 2020, 14:14
Stuntteam wrote: ↑13 Mar 2020, 00:48 Perhaps a lot of resets..?
This is likely. Indeed, the firmware sends two commands to RFLink at startup : 10;ping; and 10;version;
Code: Select all
rflinkSerialTX.println(F("10;ping;"));                       	// Do a PING on startup
delay(100);
rflinkSerialTX.println(F("10;version;"));                   	// Ask version to RFLink

After booting up you should be fine with just looking at:
20;00;Nodo RadioFrequencyLink - RFLink Gateway V1.1 - R48;
The ping command you only need to send to RFlink IF there has not been any communication from RFLink's side for <timeout> seconds where you probably stick to 30 seconds.. In case of timeout send ping and check for pong as a sign of RFlink still running but not having any RF communication.
In all other cases, make sure you do not send unneccesary commands like ping/version etc. to RFLink

955 · #12 Post by **955** » 14 Mar 2020, 12:35

Thanks for suggestion on how to debug and proceed.
I am not fully aware on how how to carry out these steps but it is a great opportunity to learn. I usually will work it out after some time.

I thought of insufficient powersupply might be the issue so to rule that out, I use 5V/2.3A usb plug which I connect to the RFLink USB port.
I reckon RFlink should provide nodeMCU with sufficient power as this is how the RFLink/nodeMCU kit it is designed. Don't you think?

What will enabling Serial Debug in espRFLinkMQTT give me?
Any additional and useful info?

Stay tuned and thanks for your support!

seb82 · #13 Post by **seb82** » 14 Mar 2020, 13:57

Forget RFLink wifi kit for now. Just connect your computer straight to the NodeMCU micro USB alone. Then you open Arduino IDE Serial Monitor and try to send some commands as if you were the RFLink (lots of examples in the protocol reference). Idea is to check whether this is stable or not alone. You can open the web interface in parallel as a second step.

Uncommenting "#define SERIAL_DEBUG" will provide lots of information in the serial monitor. And it should help identify why it reboots.

955 · #14 Post by **955** » 15 Mar 2020, 00:28

Dead stable!

I posted the strings that I received from RFLink only to the serial monitor. Works like a charm and dead stable.
This is full transcript from serial monitor after reboot and showing what I sent:

Code: Select all

00:05:38.471 -> Rebooting device...
00:05:38.958 -> Not connected, retrying in 1s
00:05:39.059 -> I guess this is my password.
00:05:40.144 -> Init rflink serial done
00:05:40.144 -> Connecting to Stenstrom24G ...
00:05:41.141 -> 1 2 3 
00:05:43.166 -> 
00:05:43.166 -> WiFi connected
00:05:43.166 -> IP address:	 192.168.1.214
00:05:43.166 -> MQTT connection state : 0
00:05:43.166 -> Ready for OTA on IP address:	192.168.1.214
00:05:43.200 -> HTTPUpdateServer ready
00:05:43.200 -> HTTP server started
00:05:43.200 -> 
00:05:43.267 -> 10;ping;
00:05:43.383 -> 10;version;
00:05:43.383 -> Uptime : 0 min
00:06:02.978 -> Enabling MQTT debug...
00:06:34.218 -> 
00:06:34.218 -> === RFLink packet ===
00:06:34.218 -> Raw data = 20;03;FineOffset;ID=00b7;TEMP=00d8;HUM=38;
00:06:34.253 -> MQTT topic = rflink/FineOffset-00b7/ => {"TEMP":21.6,"HUM":38}
00:06:34.253 -> 
00:06:34.253 -> 
00:06:59.233 -> 
00:06:59.233 -> === RFLink packet ===
00:06:59.233 -> Raw data = 20;04;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK;
00:06:59.268 -> MQTT topic = rflink/Cresta-2101/ => {"TEMP":22.0,"HUM":40,"BAT":"OK"}
00:06:59.268 -> 
00:06:59.268 -> 
00:07:14.173 -> 
00:07:14.173 -> === RFLink packet ===
00:07:14.173 -> Raw data = 20;05;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK;
00:07:14.173 -> MQTT topic = rflink/Cresta-2801/ => {"TEMP":20.2,"HUM":57,"BAT":"OK"}
00:07:14.173 -> 
00:07:14.173 -> 
00:07:26.223 -> 
00:07:26.223 -> === RFLink packet ===
00:07:26.258 -> Raw data = 20;06;Cresta;ID=2F01;TEMP=00d6;HUM=39;BAT=OK;
00:07:26.258 -> MQTT topic = rflink/Cresta-2F01/ => {"TEMP":21.4,"HUM":39,"BAT":"OK"}
00:07:26.258 -> 
00:07:26.258 -> 
00:07:43.182 -> 
00:07:43.182 -> === RFLink packet ===
00:07:43.182 -> Raw data = 20;07;FineOffset;ID=00b7;TEMP=00d8;HUM=38;
00:07:43.182 -> MQTT topic = rflink/FineOffset-00b7/ => {"TEMP":21.6,"HUM":38}
00:07:43.216 -> 
00:07:43.216 -> 
00:07:52.390 -> 
00:07:52.390 -> === RFLink packet ===
00:07:52.390 -> Raw data = 20;08;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK; 
00:07:52.390 -> MQTT topic = rflink/Cresta-2101/ => {"TEMP":22.0,"HUM":40,"BAT":"OK"}
00:07:52.425 -> 
00:07:52.425 -> 
00:08:07.564 -> 
00:08:07.564 -> === RFLink packet ===
00:08:07.564 -> Raw data = 20;09;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK; 
00:08:07.564 -> MQTT topic = rflink/Cresta-2801/ => {"TEMP":20.2,"HUM":57,"BAT":"OK"}
00:08:07.564 -> 
00:08:07.564 -> 
00:08:19.831 -> 
00:08:19.831 -> === RFLink packet ===
00:08:19.831 -> Raw data = 20;0A;Cresta;ID=2F01;TEMP=00d6;HUM=39;BAT=OK; 
00:08:19.864 -> MQTT topic = rflink/Cresta-2F01/ => {"TEMP":21.4,"HUM":39,"BAT":"OK"}
00:08:19.864 -> 
00:08:19.864 -> 
00:08:28.999 -> 
00:08:28.999 -> === RFLink packet ===
00:08:28.999 -> Raw data = 20;0B;FineOffset;ID=00b7;TEMP=00d8;HUM=38; 
00:08:29.034 -> MQTT topic = rflink/FineOffset-00b7/ => {"TEMP":21.6,"HUM":38}
00:08:29.034 -> 
00:08:29.034 -> 
00:08:40.323 -> 
00:08:40.323 -> === RFLink packet ===
00:08:40.323 -> Raw data = 20;0D;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK; 
00:08:40.323 -> MQTT topic = rflink/Cresta-2801/ => {"TEMP":20.2,"HUM":57,"BAT":"OK"}
00:08:40.357 -> 
00:08:40.357 -> 
00:08:50.757 -> 
00:08:50.757 -> === RFLink packet ===
00:08:50.757 -> Raw data = 20;0E;Drayton;ID=d290;SWITCH=18;CMD=OFF; 
00:08:50.757 -> MQTT topic = rflink/Drayton-d290/ => {"SWITCH":"18","CMD":"OFF","SWITCH18":"OFF"}
00:08:50.791 -> 
00:08:50.791 -> 
00:09:00.292 -> 
00:09:00.292 -> === RFLink packet ===
00:09:00.292 -> Raw data = 20;10;Cresta;ID=2101;TEMP=00dc;HUM=40;BAT=OK; 
00:09:00.326 -> MQTT topic = rflink/Cresta-2101/ => {"TEMP":22.0,"HUM":40,"BAT":"OK"}
00:09:00.326 -> 
00:09:00.326 -> 
00:09:12.082 -> 
00:09:12.082 -> === RFLink packet ===
00:09:12.082 -> Raw data = 20;11;Cresta;ID=2801;TEMP=00ca;HUM=57;BAT=OK; 
00:09:12.082 -> MQTT topic = rflink/Cresta-2801/ => {"TEMP":20.2,"HUM":57,"BAT":"OK"}
00:09:12.082 -> 
00:09:12.082 -> 
00:09:25.887 -> 
00:09:25.887 -> === RFLink packet ===
00:09:25.887 -> Raw data = 20;12;AlectoV3;ID=30b7;TEMP=80b8;HUM=38;BAT=OK; 
00:09:25.921 -> MQTT topic = rflink/AlectoV3-30b7/ => {"TEMP":-18.4,"HUM":38,"BAT":"OK"}
00:09:25.921 -> 
00:09:25.921 -> 
00:10:43.380 -> Uptime : 5 min

And this is what I saw in webinterface:

: v2_80MHz_nodeMCU_only_noRFLink_1.JPG (141.67 KiB) Viewed 116772 times

So nodeMCU seems to work flawless. That is good.

Question is why nodeMCU is reset so often.

Any ideas what to look for now?
Could it be that the reset happens at every reception of a 433MHz message? From a message frequence point of view it makes sense.

seb82 · #15 Post by **seb82** » 15 Mar 2020, 17:36

Well, it is difficult to help you here.

Some ideas :
- Comment the lines mentionned above that send a ping and version command on startup and see whether it helps (you can try to ping continously the ESP or look at running time on web interface).
- Remove antenna so that nothing gets to the RFLink. Check whether NodeMCU resets. Then send a 433 MHz signal.
- Try another firmware for the RFLink Wifi Gateway.
- Try direct connection from RFLInk RX/TX to TX/RX of the NodeMCU (ie without the RFLink Wifi gateway). Be aware that they are different voltage 5V / 3.3V so there is a risk for the NodeMCU (you are supposed to use a Logic Level Converer though I have done it many times with esp8266). Make sure there is only one power supply and a common ground.

Good luck and let us know.

955 · #16 Post by **955** » 15 Mar 2020, 22:24

Thanks for your ideas and support!

I was thinking to check some voltages on the wifi gateway first.
Secondly to have the nodeMCU on a breadboard and provide RX/TX from RFLink as you suggest on your last bullet.
As both the nodeMCU and RFLink seems to work standalone I will focus on the interface between them.

I will probably do the other bullets as well.

I will surely keep you updated, there is not so much spare time this week though.
Sad, as it now starts to get interesting.

955 · #17 Post by **955** » 03 Apr 2020, 08:07

Hi again,
I am still facing som issues.
Restarts still occur and after disconnecting antenna so restart issues seems not to be aligned with receiving RFlink messages.

I have also connected nodeMCU directly to RX/TX on RFlink and at one point, for a short while I actually saw RFlink messages coming in as supposed. Unfortunately I had to move the whole setup and I have not succeeded again. I have some more ideas that I will work on.

I also later saw that seb821 had updated the espRFLinkMQTT package so I have switched to that.
Looks good. Thanks!
Using the new package I have turned of ID filtering and as I understand that I would also need to change the VERSION to make sure the ID is updated.
Is that correct?

Additionally, I am not able to change ID filtering online through the webinterface as stated in the documentation.
There is no page on IP#_for_espRFLinkMQTT/settings to host this.

One thing that strikes me - the webinterface is completely blank.
As no RFlink messages seem to come through I of course do not expect to see any of these.
But are there not any messages originating from espRFLinkMQTT that is posted as well? I thought so.

Well main concern is still that RX/TX does not seem to come through. I will borrow a oscilloscope during the weekend to see if I can catch the pulsetrain.

That's all for now, any suggestions on how to proceed are very welcome.

seb82 · #18 Post by **seb82** » 04 Apr 2020, 07:24

For restart, it is difficult to help.

If ID filtering is turned off, the VERSION parameter does not matter. In fact, IP filtering configuration is stored in eeprom memory and VERSION is used to detect a change.

In the last github version, the page to change configuration is no more /settings but /configuration. The is a link on the main page only if ID filtering it turned on. If turned off, the page will appear with an empty table.

To test RX/TX, you can send a 10;ping; command (from the webinterface of with MQTT) and you should get a PONG response. If not, communication between esp and rflink does not work.

I would also recommend to enable MQTT debug with the link in the top menu (needs to be done every time esp is resetted) and see what comes in the MQTT server. Just in case there is a javascript issue not updating data in the webinterface (or point to /data.txt to see the last received information).

What do you mean by completely blank . No data coming or the webpage does not show anything (no title, menu, etc.) ?

seb82 · #19 Post by **seb82** » 10 Apr 2020, 11:02

Hello,
I have just updated the dev branch with a new version briging lots of improvements and stability: https://github.com/seb821/espRFLinkMQTT/tree/dev
In particular, the web inferface should not be blocked in case of MQTT connection failure, which should help for troubleshooting.
Please let me know if you get a chance to test it. This version will most likely become the first stable release.

seb82 · #20 Post by **seb82** » 10 Apr 2020, 11:38

@955

I have re-opened an old issue here: https://github.com/seb821/espRFLinkMQTT/issues/3

It seems that there is a watchdog on RfLink Wifi board which would well explain the behavior you are experiencing.

I can try to implement the code, but I need someone to test it. Let me know.

955 · #21 Post by **955** » 10 Apr 2020, 23:16

Hi,

of course seb82!
I will test and report.
I will install your latest espRFLinkMQTT update tomorrow.

Bring it on, tell me what to look for and how to test.
Thanks for looking into it!

seb82 · #22 Post by **seb82** » 11 Apr 2020, 10:04

Great,

I did my best to adapt the code from information I found on ESP Easy and RFLink documentation.

Specific version uploaded in this branch: https://github.com/seb821/espRFLinkMQTT ... wifi-board.

I have even put a .bin file that you can flash directly if you want. In this cas, you need to wait 1 min for access point to show-up, connect to it, go to http://192.168.4.1/infos, update wifi settings and reset esp. Go back to your normal wifi network after that.

To check it works, try two things in the webinterface:
- Send a '10;ping;' command from the main page and see whether you get a '20;XX;PONG;' response
- In system tab, check uptime to make sure it does not keep resetting.

955 · #23 Post by **955** » 12 Apr 2020, 00:23

Great work seb82!

I now get readings from RFLink picked up by NodeMCU running your tailored SW!
Sending a 10;ping; results in an immediate 20;64;PONG; response.
Uptime so far is 28min, I need to go to system tab to see that printout.

Anyway - This is a huge step forward.
Please enlighten me about the issue seb82

seb82 · #24 Post by **seb82** » 12 Apr 2020, 21:06

Great news !

I shall include it in the next version of the software then.

What issue are you talking about ?

I can see that MQTT is not connected. Just need to go to the system tab and fill-up parameters (server, port, user and password if any).

955 · #25 Post by **955** » 12 Apr 2020, 21:22

I was referring to the i2c watchdog issue. Nothing else.
Yes, MQTT is not connected as I have not proceeded with the MQTT connection - there have been no readings to care for.
Now is the time!

Additionaly the new version is a lot faster and response is almost immediate.

Great work and again thanks!

/Niklas

seb82 · #26 Post by **seb82** » 13 Apr 2020, 11:53

Good !

Yes, It should even be better once you configure MQTT as otherwise it tries to connect every ten seconds which may generate a delay if trying to load a page at that very moment.

I spent quite some time on the interface to get it faster and use less memory to avoid crashing the esp which was happening a lot before. It is far from being perfect as I am not a c programer, but I learnt a lot and did my best. Just a few more things to add to the dev branch and I will update the main repository.

955 · #27 Post by **955** » 30 Apr 2020, 07:31

Hi Seb, hope you are doing good.
Any projections on when you will update the master branch?

seb82 · #28 Post by **seb82** » 30 Apr 2020, 12:24

Hi,

Actually, I was planning to do it last week but I faced some stability issues that were in fact due to my home wifi setup.

I want to rewrite completely the help file, so this may require some extra time.

For now, I have just published the most recent code to the dev branch: https://github.com/seb821/espRFLinkMQTT/tree/dev

Most likely this code will be used for version 1 release.

It would be nice if you get a chance to test it as I cannot be 100% sure for the RFLink wifi board.

Also - if possible - please try to flash the file named "espRFLinkMQTT_generic_core_263_1MB_DOUT_rflink-wifi-board.bin". A wifi network named espRFLinkMQTT should appear 1 minute after powering on the esp, and then after connecting to it you can setup your wifi credentials at url "http://192.168.4.1/infos". It would be a good opportunity for me to confirm everything works as expected for someone else.

955 · #29 Post by **955** » 02 May 2020, 01:01

Hi!

I usually like to edit the config file and compile, but I will according to your suggested scenario.
I intend to test late tomorrow.

May I ask what you use to receive your MQTT values?
I am using and setting up Home Assistant, where I am still learning a lot.
Intend to include Grafana and NodeRed eventually when I get this sorted.

seb82 · #30 Post by **seb82** » 02 May 2020, 01:42

If you can test it is good, though the most important is to test the rflink board support which can be enabled with the config file.

On my side, I use Jeedom which is a great home automation system developped in France. It comes with a plugin for MQTT. The nice part of it is that most of the configuration can be done from the web interface, no need for text configuration files as for Home Assistant (never tested it though, just my understanding from some comparisons I read). Unfortunately, the Jeedom english community is quite limited at the moment.

happytm · #31 Post by **happytm** » 02 May 2020, 01:43

I would use this app for test purpose : https://play.google.com/store/apps/deta ... h&hl=en_US .

If you are going to use Node-Red please keep eye on this very promising repo : https://github.com/Christian-Me/remote-device-table .

Thanks.

955 · #32 Post by **955** » 03 May 2020, 08:53

Hi,

unfortunately I had, and still have, difficulties to access the nodeMCU so I havn't been able to try OTA with new bin-file.
Later today I will try regular compile and config update.

Thanks also for suggestions and tips on your systems. Plenty of interesting stuff!
My french is non-existant so Jeedom doesn't seem to be the way to go.

955 · #33 Post by **955** » 07 May 2020, 23:13

Hi, I have continued to test the new Dev version but somehow I don't get the MQTT connection to the broker.
So this makes it difficult to access the webinterface, ESP webserver is not responing even if I see that connection exists on wifi.
I have mainly tried the confuguration.h way but I recently tried the .bin file as well, but the wifi newtork is ESP_DCD7 something shows-up but I am not able to connect to it. I have tried to connect after powercycling a couple of times. I can't connect.

I am also thinking that there might be a startup sequence between RFlink/nodeMCU that should be kept.
So I wanted to set

Code: Select all

#define DEFAULT_MEGA_AUTO_RESET_INTERVAL 10 * 60 * 1000

just to make sure that there is a recovery function in place.

However, which setting should I use for a RFlink bord?
Like this?

Code: Select all

#define DEFAULT_MEGA_RESET_PIN 16	// ESP pin connected to MEGA reset pin

I will check/measure it later otherwise but in case you have it...

Now I am now again testing with the configuration.h variant.

Tomorrow evening I will try the "old" version

seb82 · #34 Post by **seb82** » 08 May 2020, 12:44

Hi,

Thanks for your feedback.

It is weird that you see ESP_DCD7 as it should be espRFLinkMQTT, or more exacthly what is defined by this line:

Code: Select all

#define HOSTNAME "espRFLinkMQTT"

For MQTT, it will be able to connect only once esp it on the proper Wifi (the network where the MQTT server is).

Sometimes it helps if you blank the esp completely. You would find such bin files for example in an ESP Easy release.

For DEFAULT_MEGA_AUTO_RESET_INTERVAL, leave it to zero to disable it, it is better. For DEFAULT_MEGA_RESET_PIN, leave it to -1.

For the RFLink board, you need to uncomment this line at the end of the config.h file :

Code: Select all

#define RFLINK_WIFI_BOARD

Let me know if you make any progress.

955 · #35 Post by **955** » 11 May 2020, 22:29

Thanks for insights. Just wanted to let you know that I havn't been able to test yet. I will feedback as soon as I had the chance.

happytm · #36 Post by **happytm** » 12 May 2020, 01:58

I am interested in using your library specially your web UI part of it. I do not have any RF devices but I wanted to use it with barebone ESP8266 and BME280 sensor.

Is it possible to replace all received data from RF devices by MQTT messages in JSON format and display it with your web UI? I tried to strip RF related code but it is too complicated for me. My code publishes MQTT messages from the data it receives from some slave (ESP8266) devices in 2 different format as shown below:

Published topic 'SensorValues with payload {"Location":"Livingroom","Voltage":2.62,"Sensor1":"temperature","SensorValue1":1,"Sensor2":"humidity","SensorValue2":2,"Sensor3":"pressure","SensorValue3":170,"Sensor4":"light","SensorValue4":49}

Published topic 'Livingroom/voltage with payload 2.62
Published topic 'Livingroom/temperature with payload 1
Published topic 'Livingroom/humidity with payload 2
Published topic 'Livingroom/pressure with payload 170
Published topic 'Livingroom/light with payload 49
Published topic 'DeviceStatus with payload {"Location":"Livingroom","rssi":-72,"mode":0,"ip":6,"channel":7,"sleeptime":1,"uptime":140}
Published topic 'Livingroom/rssi with payload -72
Published topic 'Livingroom/mode with payload 0
Published topic 'Livingroom/ip with payload 6
Published topic 'Livingroom/channel with payload 7
Published topic 'Livingroom/sleeptime with payload 1
Published topic 'Livingroom/uptime with payload 140
Published topic 'SensorValues with payload {"Location":"Bedroom1","Voltage":2.62,"Sensor1":"level","SensorValue1":8,"Sensor2":"presence","SensorValue2":0,"Sensor3":"motion","SensorValue3":66,"Sensor4":"custom","SensorValue4":31}

Thanks.

seb82 · #37 Post by **seb82** » 12 May 2020, 18:41

happytm wrote: ↑12 May 2020, 01:58 I am interested in using your library specially your web UI part of it. I do not have any RF devices but I wanted to use it with barebone ESP8266 and BME280 sensor.
Is it possible to replace all received data from RF devices by MQTT messages in JSON format and display it with your web UI?

I guess it is feasible. My advise is for you to use ESP Easy that has a nice web interface and supports BME280 directly.

seb82 · #38 Post by **seb82** » 12 May 2020, 18:43

955 wrote: ↑11 May 2020, 22:29 Thanks for insights. Just wanted to let you know that I havn't been able to test yet. I will feedback as soon as I had the chance.

No worry, I was busy anyway. I have also started to rework a little bit the presentation and shall double check this issue with the access point name.

happytm · #39 Post by **happytm** » 12 May 2020, 20:37

I have been using ESPEasy for long time but it is overkill plus I am using custom communication protocol in this project which ESPEasy does not support. Can you please give some hints regarding how to remove all RF related code?

Thanks

TD-er · #40 Post by **TD-er** » 13 May 2020, 09:12

happytm wrote: ↑12 May 2020, 20:37 I have been using ESPEasy for long time but it is overkill plus I am using custom communication protocol in this project which ESPEasy does not support. Can you please give some hints regarding how to remove all RF related code?

Thanks

What protocol?
If it is ESP-now, then I think you may like what I'm working on right now

seb82 · #41 Post by **seb82** » 13 May 2020, 13:57

happytm wrote: ↑12 May 2020, 20:37 Can you please give some hints regarding how to remove all RF related code?

I am confused here. No offense, but if you cannot understand how to remove RF related code, how can you hope to implement a custom protocol ?

I really believe it is a good thing that people try modifying and programming themselves (by the way, I am not a programmer at all, just spent time on it by need and curiosity). It is just that your request and goal appear inconsistent here, but maybe I missed something.

It is not easy to remove the RF code because the code itself is not really clean and properly splitted in functions or files: most things were added one by one without thinking about the global structures, definitely not the way a real programmer would do it I guess. I tried to separate some parts in the last dev version, but it was quickly going beyond my knowledge.

The only hint I can give you is to remove files RFLink.cpp and RFLink.h. Then try to compile and fix the errors. If it works, maybe you will get close to what you asked. Nevertheless, I believe you will waste your time and I advise you to start from scratch. For this, I would recommend this tutorial which is the one I used mostly in fact: A Beginner's Guide to the ESP8266

happytm · #42 Post by **happytm** » 13 May 2020, 22:54

@seb82

No offence taken.

In my post I said I already implemented my custom protocol. You said it is even hard for you who wrote this code to remove RF related stuff. I tried myself not knowing your code fully with limited time. I had little question hoping to get some easy way out with your help. But now I understand there is no easy way out. I now will dig deeper and try to find out a solution.

Thank you for your help.

happytm · #43 Post by **happytm** » 13 May 2020, 23:01

What protocol?
If it is ESP-now, then I think you may like what I'm working on right now

My protocol is here https://github.com/happytm/BatteryNode .

I will be eagerly waiting for your implementation of ESPNow.

Thanks.

seb82 · #44 Post by **seb82** » 14 May 2020, 11:55

Ok. I understand better now what you try to achieve and you are not new on the subject.

I gave it a chance and went quickly through the code trying to remove all the RF part. Actually, it was quicker than I thought thanks to the way I organized things in the most recent version. Here is where I got: https://github.com/seb821/espRFLinkMQTT/tree/norf

It does compile and after uploading it on a D1 mini it seems to work well. Some cleaning left to be done on the http server side but it should be easy to go through. For the MQTT side, it connects to the server but I disabled the callback (topic subscription). I guess it will be different on your project anyway.

Regards,

happytm · #45 Post by **happytm** » 15 May 2020, 19:23

Thank you very much for your help.

955 · #46 Post by **955** » 23 May 2020, 22:56

Hi seb82,

I finally got to spend some time with the new version, trying to work things out.

I can confirm your updates are working perfectly fine.
I had to do a couple of restarts of HomeAssistant and the MQTT broker inside HomeAssistant, but that is probably not at all related to your code.

It has now been online and collecting RFLink data and passing it on to HomeAssistant for the last 23h.

Have a nice sunday!

/Niklas

mrshark · #47 Post by **mrshark** » 25 May 2020, 10:52

hi, i just flashed my wemos mega with espRFLinkMQTT_generic_core_263_1MB_DOUT_rflink-wifi-board.bin
put in wifi+mqtt info and it's working as expected, and it seems faster than the previous tasmota in reporting the rf remote button pressed... anyone knows which is the pin to be set on this board for the "mega reset"? thanks

konehead · #48 Post by **konehead** » 11 Apr 2021, 12:40

Hi, i have the same configuration as the topic starter. I started with the Github production version (link, first topic), the ESP was rebooting (RFLINK ping/poing) multiple times. This morning i switched over to the DEV version and first impressions are verry good! It is almost one year silent in this topic. When will the DEV version ready for production?

KUDDO’S TO SEB82!!

seb82 · #49 Post by **seb82** » 13 Apr 2021, 01:40

Yes indeed, the dev branch is really a huge gap with a lot of cleanup and optimization.

Unfortunately, there was still some work left to be done before releasing (mainly on the help part and adding option for retain flags). And I did not get much time since then and focused on other projects.

Or maybe I should release it as it is now. It has been running on one device for a year now with no problem.

konehead · #50 Post by **konehead** » 13 Apr 2021, 21:36

seb82 wrote: ↑13 Apr 2021, 01:40 Yes indeed, the dev branch is really a huge gap with a lot of cleanup and optimization.

Unfortunately, there was still some work left to be done before releasing (mainly on the help part and adding option for retain flags). And I did not get much time since then and focused on other projects.

Or maybe I should release it as it is now. It has been running on one device for a year now with no problem.

The DEV branch is really good. You should promote it to a formal release. I am not a developer, but can I help you with the latest things to be done? I believe that you did a very good job, let's finish the last mile together. I can write a help file and do some testing - in case if it supports you. I also believe RFLINK should mention this solution on their website (in case you are ok with this). I do like this solution, because there is no serial connection required between my RPI en the RFlink

Who is online