Global Sync with 20x4 LCD and BME280s - No info displayed on LCD

[TD-er]

If you exchange settings, are always the same physical devices causing problems?

Can you make a list of MAC addresses and IP-addresses of all nodes?
Just to make sure no 2 devices have the same.

[robatbentley]

Re "If you exchange settings, are always the same physical devices causing problems?" - The same physical devices change behaviour when settings are modified. However, any initialised device that doesn't go through the 20 sec countdown seems to have more problems re global sync.

...and details requested...

BME280 Sensor...
AP MAC: A2-20-A6-1C-0C-08
IP: 192.168.1.8

...and the LCD nodes...

LCD1:
AP MAC: A2-20-A6-1C-46-08
IP: 192.168.1.10

LCD2:
AP MAC: A2-20-A6-1B-2A-01
IP: 192.168.1.20

LCD3:
AP MAC: 62-01-94-1F-85-08
IP: 192.168.1.11

LCD4:
AP MAC: A2-20-A6-15-F5-08
IP: 192.168.1.4

LCD5:
AP MAC: 62-01-94-1F-7A-08
IP: 192.168.1.21

[Shardan]

I've made a simple test breadboard with two nodeMCU's and a BMP180 sensor from my shelf.

I've had the same problem as the thread opener - until I configured the sensor node to connect to my FHEM home controller and send data.
Then i get readings on the second node.

So it seems GlobalSync only works if the data transfer to a home controller is activated.

At dev's: Is this a bug or is that a feature?

Regards
Shardan

[TD-er]

[...]
So it seems GlobalSync only works if the data transfer to a home controller is activated.

At dev's: Is this a bug or is that a feature?
[...]

Sounds like a (serious) bug.
Will look into it.
I might be the one who introduced it.

[Shardan]

^+1
Thanks

[robatbentley]

...and a thanks from me too!
Can you let me know when there's something to try out?

[TD-er]

Ofcourse.
I was looking for this thread to link it into a new Github issue for fixing this.
Let's hope I get to it this evening.

[TD-er]

I've been looking through all the code for hours now and I find this part a bit strange:

Almost every call to a plugin with "PLUGIN_READ" will return 'success = true'. Well at least when a value is read.
Except P012_LCD.
That one returns "success = false"
Perhaps with the idea no value is being read.


In ESPEasy.ino in

Code: Select all

void SensorSendTask(byte TaskIndex)

There is a check which does a call with PLUGIN_READ:

Code: Select all

    if(Settings.TaskDeviceDataFeed[TaskIndex] == 0)  // only read local connected sensorsfeeds
      success = PluginCall(PLUGIN_READ, &TempEvent, dummyString);
    else
      success = true;

    if (success)
    {
      for (byte varNr = 0; varNr < VARS_PER_TASK; varNr++)
      {
        if (ExtraTaskSettings.TaskDeviceFormula[varNr][0] != 0)
        {
           [...]
        }
      }
      sendData(&TempEvent);
    }

This sendData does also do other things and eventually do a checkUDP().
It is being called from other controllers also, which may explain why it would work when some controller is enabled.

As a test, I will move the call to sendData outside the scope of the if(success) check, since the TempEvent is not changed within that if-scope.

See pull request https://github.com/letscontrolit/ESPEasy/pull/896

If someone could test it, that would be great

[TD-er]

I was just thinking about it. There are better ways to fix it, given it is the problem.

So if anyone could test it is a "fix", then I will write a better fix for it.
This will result in more updates than desired.

[TD-er]

Hopefully the last version of my pull request will result in less frequent unneeded updates.
Could someone test it?
https://github.com/letscontrolit/ESPEasy/pull/896

Eventually I want to change the way global sync is handled.
It is essentially just a controller and thus it should be treated as one, not as a special use case. Those will always lead to strange and hard to debug issues.
I don't like exceptions, especially in software design

[robatbentley]

Sorry TD-er, didn't see your update. I'll give it a test tonight.

Update: I rebuilt 2 x 8266 nodes (loaded with zeros and then the latest build of ESP_Easy_v2.0-20180221_normal_ESP8266_4096), one for the LCD (192.168.1.10) and the other for the BME280 (192.168.1.8) sensor.
I managed to get the global synch working as far as valid sensor values appearing in the LCD nodes device list. ...but still no sensor values appearing on the LCD itself. I tried my usual trick of submitting changes to the BME280 sensor but to no effect.

I noticed that the LCD device had a new option called "LCD command Mode:" but left this as the default of "Continue to next line (as in v1.4)"

I've attached a few LCD screen-shots (apologies for the repetition of some of them - can't get rid of them!) but if further details are needed then just ask. ...and if there's there're any changes you'd like me to test then get back to me again.

[robatbentley]

I've uploaded the latest firmware version ESP_Easy_v2.0-20180228_normal_ESP8266_4096 on both my LCD and sensor nodes but still the same problem.
Can anyone else duplicate this issue? ...as, so far, it seems to be just me with the problem.

[Martinus]

Can you try with the latest version and check the logging on both sender and receiver. Use debug level DEBUG_MORE.
You should see stuff like this:

Sending unit
150500 : C013 : Send UDP message to 1
150511 : C013 : Send UDP message to 3
150521 : C013 : Send UDP message to 4
150532 : C013 : Send UDP message to 5
150543 : C013 : Send UDP message to 6
150553 : C013 : Send UDP message to 7
150624 : C013 : Send UDP message to 14
150634 : C013 : Send UDP message to 15
150665 : C013 : Send UDP message to 18
150786 : C013 : Send UDP message to 30

Receiving unit:
11678439 : UDP : 60:01:94:0F:A2:3F,192.168.0.102,2
11688458 : C013 : msg 5 2 18 10 10
11689498 : UDP : 5C:CF:7F:0F:50:BC,192.168.0.106,6
11690156 : C013 : msg 5 2 18 11 11

Check if the sending units actually sends a UDP message to the receiving unit.
And check if the receiving unit gets it. It should say C013: msg 5 x x x x

[giobbe]

Hi,
But does it work or not at today?
Thanks
Giobbe

[blb4lci]

Can you try with the latest version and check the logging on both sender and receiver. Use debug level DEBUG_MORE.
You should see stuff like this:
.......
Receiving unit:
11678439 : UDP : 60:01:94:0F:A2:3F,192.168.0.102,2
11688458 : C013 : msg 5 2 18 10 10
11689498 : UDP : 5C:CF:7F:0F:50:BC,192.168.0.106,6
11690156 : C013 : msg 5 2 18 11 11

Check if the sending units actually sends a UDP message to the receiving unit.
And check if the receiving unit gets it. It should say C013: msg 5 x x x x

Hi Martinus, I do see these messages on sending and receiving unit, but I don't get the task visible on the receiving unit. What Do I have to do to get this fixed?

[Martinus]

Can you try with the latest version and check the logging on both sender and receiver. Use debug level DEBUG_MORE.
You should see stuff like this:
.......
Receiving unit:
11678439 : UDP : 60:01:94:0F:A2:3F,192.168.0.102,2
11688458 : C013 : msg 5 2 18 10 10
11689498 : UDP : 5C:CF:7F:0F:50:BC,192.168.0.106,6
11690156 : C013 : msg 5 2 18 11 11

Check if the sending units actually sends a UDP message to the receiving unit.
And check if the receiving unit gets it. It should say C013: msg 5 x x x x

Hi Martinus, I do see these messages on sending and receiving unit, but I don't get the task visible on the receiving unit. What Do I have to do to get this fixed?

When UDP communication is ok, you should open and submit the sending device task. This should send a message with the sensor config data and receiving units should create a task automatically (but only if that task is unused!)

[blb4lci]

Thanks Martinus, now it's working again! The task was already active on the sending unit before, now with the change of global sync to a controller it's nessesary to submit again, good to know.