@wint0178 Yes, 2.0.0 launched very recently

@fsgrazzutti It is good news. let us know if you see the issue again. Thanks!

Hi Folks, sorry for the delay in responding... only just got a chance to get back to this again... @skywatch Yes, I just checked and found I was also unable to select a sensor variable for any object on the dashboard either - the Sensors variable list was just empty. Thanks! @jkandasa This snapshot version fixed the issue for me as well - thank you very much!!

@sandr I believe netty dependent package upgrade might resolve this warning. But I am not sure at this point.

@jkandasa Thank you sooooo much for that! It was the crucial bit of info/understanding that I was missing. It works fine now! If this turns out to be the same in myc2.0, I'll write a tutorial for it.

@jkandasa thank you !

If others will arrive here searching for a similar issue: in my case the final solution has been changing the Arduino Uno I was using as ethernet gateway.

@wkwj00 There is no way to show dashboard without login. Sure, I will take a note of this request for v2.x. Thanks for your support!

@jkandasa increasing the memory did it. thanks again !

Intresting thing happened this weekend. The nodes all appeared 'down' again and yet in all screens (resources and topology) the GW was showing as up. It was a mystery. Then, I tried to turn on some lights, it worked. So this time MyController is not getting data from the nodes, but is able to send commands to the nodes correctly. I am beyond puzzled by this as it is no longer a GW faliure nor is it a NRF24l01 lock up.

@jkandasa thanks a lot !

@pw44 Good!, Welcome to the forum!

I opened an issue in github also. RFlink protocol is here http://www.rflink.nl/blog2/protref The error message is referred to the message show above, this one 20;4e;Alecto V1;ID=0005;WINDIR=0012;WINGS=001c;BAT=OK;\r 20 mean a messagr from RFlink 4e is the message number ID is the sensor ID WINDIR is the wind direction WINGS is the wind speed gust Al messages are in ASCIII, there is not any NaN or strange values like the DHT ones. It happens with all WINDIR messages, no one is decoded. Data are captured and decoded from a meteo station sensors at 433MHz But you give me a good suggestion, maybe there is a character in message not printed in the error, so I will check on a PC in HEX also. Edit: Check done, all ascii chars plus CR+LF at the end I don't understand why this happens on this message and not with others. I watched on my controllers code and I don't see any bug.

Hi, not really, I sent a request and got 3 replies. cause 1: I discovered that OpenHab was enabled at the same time even if I removed the gateway from its things (just wanted to give it a try), so I just unistalled it and the problem disappeared. For a while... cause 2: I was using MYSController for real time debugging of my sensors, but without enablig the "RX only" mode. Once enabled the RX only mode, the problem disappeared completely. So, there's nothing wrong with MyController, but rather a weird scenario caused by me. Enabling ACK on both sensors and Mycontroller I could figure out what was going on. So, false alarm, sorry ! Franco.

@Avamander could you please post me an example of DHCP renewal? I investigated the ICMP ping idea but I've not been able to get something working, since the ping seems to interfere with GW code. Did you manage to use it in a mysensors GW?

@jkandasa No problem..... Mysteriously it seems to have resolved itself. Today is 'update' day for the pi and I thought I'd wake to a dead http connection. But no! - there was mycontroller running as normal. Maybe I just didn't give it enough time to settle down in previous tests......Ah well, it's alright at the moment so this is solved now!

@Daniele Yes, it is calling mycontroller.mv.db. I tried with that syntax, but the error I receive is : SQL Exception: No suitable driver found for mycontroller I try this locally and let you know.

@skywatch Just a quick update - ...... Keep the receive section clean - I took all the 'if' and 'elseif' out of receive and into the main loop - This is good practice. So now it looks like this...... // process incoming message void receive(const MyMessage &message) { if (message.sensor == CHILD_ID_GETFORECAST && message.type == V_FORECAST) { forecast = (message.getString()); NewForecast = 1; } } The NewForecast is there to alert the main loop to a new incomming value to be tested and updated.