Domoticz:

Starting with a native implementation, thanks to Ad for providing the RF interfaces.

Maybe best (for domoticz) to continue on the forum,
i need serial logs of all possible combinations and meaning

node-id;child-sensor-id;message-type;ack;sub-type;payload

we developers probably have to do some special tricks to get some nice sensors

for instance, it would be nice if there where subtypes for:

• Temp+Hum
• Temp+Hum+Baro
• Kwh+Watt
• Wind+Gust+Direction

I can not watch this forum, if you want to contribute, plz use the domoticz forum

As for Domoticz, you could make a forum post what you would like to see changed...
It might be a bit difficult to setup initially, working with idx values, but when you just go to the devices table, you can quickly find the correct idx.
As for the value type/name, that is stored in the correct influxdb password

So the series name comment does not make sense.

Now, the reason why i choose for the idx value, instead of a name, is because when you rename a device, the idx stays the same.
But on the other hand, when you have a cheap temperature sensor, and the battery runs out, you probably get a new device-id when inserting new batteries, so the idx changes.
You will also have to deal with scenarios when using other solutions.

As for username/password support, this will be added soon (i need to find some time, unless someone beats me to it).

If you have a better solution, you can always propose this on the forum/github

The code looks wrong to me

this

MyMessage msgC(SSR_B_ID, V_STATUS);

should probably be

MyMessage msgC(SSR_C_ID, V_STATUS);

The distance sensor is supported in the beta version of Domoticz

The code looks wrong to me

this

MyMessage msgC(SSR_B_ID, V_STATUS);

should probably be

MyMessage msgC(SSR_C_ID, V_STATUS);

As for Domoticz, you could make a forum post what you would like to see changed...
It might be a bit difficult to setup initially, working with idx values, but when you just go to the devices table, you can quickly find the correct idx.
As for the value type/name, that is stored in the correct influxdb password

So the series name comment does not make sense.

Now, the reason why i choose for the idx value, instead of a name, is because when you rename a device, the idx stays the same.
But on the other hand, when you have a cheap temperature sensor, and the battery runs out, you probably get a new device-id when inserting new batteries, so the idx changes.
You will also have to deal with scenarios when using other solutions.

As for username/password support, this will be added soon (i need to find some time, unless someone beats me to it).

If you have a better solution, you can always propose this on the forum/github

+1, thanks, was looking for this as well

Thanks, you mean from the board manager downgrade "Arduino AVR Boards" from 1.16.13 to 1.16.11
I will try so this weekend

But... this seems an arduino library... why, with this library and mysensors 1.5, there is no problem ?
I also think it was OK somewhere during the beta period of 2.0, but i could be wrong here as this IDE is quite new.
But... because 1.5 is working, i suspect a problem in the 2.0 code....

Hope either party gets this sort out quickly... i was pulling my hair because i thought i broke my gateway

@tekka said:

@GizMoCuz did you uncomment

#define MY_DEBUG

as suggested above?

Yep, see three posts up (If i disable debug, it is logging the IP Address over and over again (each second), connection is reset at that moment)

And unfortunately does not explain why version 1.5 is running (but missing important features/fixes)

The sketch is 99,999% the same as 'GatewayW5100' except i changed:

#define MY_IP_ADDRESS 192,168,0,50 

The default Arduino ethernet server examples work perfectly

Thanks in advance !

No, the Node is resetting itself with the messages in the first post.
If i disable debug, it is logging the IP Address over and over again (each second), connection is reset at that moment

Having the exact issue as the OP, but then with a W5100 shield and a NRF24.
Reverting back to MySensors 1.5.4 solves the problem.
Now i was on a beta of 2.0 that i uploaded to the gateway quite some time ago, and this worked without issues
Something has changed in the final 2.0 release... and i want to revert that change

I use a plastic case like:
http://www.aliexpress.com/item/Free-Shipping-115-90-55MM-Waterproof-Clear-Cover-Plastic-Electronic-Project-Box-Enclosure-Case/2025251375.html

I now use the following code to read the uv value:

#define         READ_SAMPLE_INTERVAL         (50)    //define how many samples you are going to take in normal operation
#define         READ_SAMPLE_TIMES            (5)     //define the time interal(in milisecond) between each samples in  
#define         VREF 5.0f

float last_UVIndex = 0;
uint16_t uvIndexValue [12] = { 50, 227, 318, 408, 503, 606, 696, 795, 881, 976, 1079, 1170}; 

float UVRead()
{
  int i;
  float rs=0;
 
  for (i=0;i<READ_SAMPLE_TIMES;i++) {
    rs += analogRead(UV_PIN);
    delay(READ_SAMPLE_INTERVAL);
  }
 
  rs = rs/READ_SAMPLE_TIMES;
 
  return rs;  
}

float GetUVIndexFromVoltage(float voltage)
{
  float UV=0;
  int i;
  for (i = 0; i < 12; i++)
  {
    if (voltage <= uvIndexValue[i]) 
    {
      UV = float(i);
      break;
    }
  }
  
  //calculate 1 decimal if possible
  if (i>0) {
    float vRange=float(uvIndexValue[i]-uvIndexValue[i-1]);
    float vCalc=voltage-uvIndexValue[i-1];
    UV+=(1.0f/vRange)*vCalc-1.0f;
  }
  return UV; 
}

void sendUVIRMeasurements(bool force)
{
  bool tx=force;

  float sensorValue = UVRead();
  float voltage= sensorValue * (VREF / 1023.0f) * 1000.0f; //mV
  if (voltage>1170)
    voltage=1170; 
  //Serial.print("UV Analog reading: ");
  //Serial.println(voltage,2);
  float UVIndex=GetUVIndexFromVoltage(voltage);

  float diffUV = abs(last_UVIndex - UVIndex);
#ifdef MY_DEBUG
  Serial.print(F("diffUV :"));Serial.println(diffUV);
#endif
  if (diffUV > 0.1) tx = true;

  if (!tx)
    return;

  Serial.print("UVI: ");
  Serial.println(UVIndex,2);

  last_UVIndex = UVIndex;

  Serial.print("UV: ");
  Serial.println(UVIndex, 2);
  
//  send(msgUV.set(UVIndex,2));
  //Avarage
  raUV.addValue(UVIndex);
  send(msgUV.set(raUV.getAverage(),2));
}

I dont think it's a Sensor issue, rather a sketch issue....
I bought 4 UV sensors, and also experiencing this.
It could be that we need to multiply the value we send by 10 ? Or we need to do some magic after the analogRead call

From what i understand the analogRead returns a value between 0-1023

1023 stands for the maximum voltage that can be read on this pin, and equals VREF
[Source](5 volts (on 5V Arduino boards) or 3.3 volts (on 3.3V Arduino boards))
So if we use 3.3V on the arduino, then 1023 stands for 3.3V

We go back from the digital value (0-1023) to voltage with:
Source

int sensorValue = analogRead(A0);
float voltage= sensorValue * (3.3 / 1023.0);

The above sketch is using mV, so we need to multiple the voltage by 1000

float voltage= sensorValue * (3.3 / 1023.0) * 1000.0;