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 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;
I think that will solve the issue... @snow, waiting patiently for your reply
I also find it strange that at the beginning V_LIGHT correctly displays 0 or 1, and at the end 04 ? (0 = OK)
@hek, as demonstrated with the new V_CUSTOM, there is send a lot of information from domoticz -> node, and all prints well, so maybe thats a confirm that this part is working OK (at least on the nRF024)
@hek, with \n
MySensors is implemented in domoticz for a long time now... there should be nothing wrong with it.....
Also in my sketches all is received perfectly
Could there be a difference between the ESP8266 and nRF ?
I only use the nRF currently (and probably will for ever as i have 20 more chips and a lot more arduino's g)
Also i do not send anything with the word version in it, it looks this is a left over from sending the sketch information ?
I dont know how you guys get that nice colors in the log (brown/white/green), but the green number is OK, that white behind it is not
There is a small problem with domoticz regarding the light level (fixed in beta #3563)
When the slider was set to 100%, around 93% was send to the node
BUT, what domoticz sends, is OK, there is NO version stuff added (really strange your seeing this!)
I made a test sketch, and this is the output:
Starting...
send: 254-254-0-0 s=255,c=0,t=17,pt=0,l=10,sg=0,st=ok:1.6.0-beta
send: 254-254-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
read: 0-0-254 s=255,c=3,t=6,pt=0,l=1,sg=0:M
send: 254-254-0-0 s=1,c=0,t=4,pt=0,l=0,sg=0,st=ok:
send: 254-254-0-0 s=255,c=3,t=11,pt=0,l=21,sg=0,st=ok:DimmableLED /w button
send: 254-254-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.2
sensor started, id=254, parent=0, distance=1
Ready to receive messages...
read: 0-0-254 s=1,c=1,t=2,pt=0,l=1,sg=0:0
send: 254-254-0-0 s=1,c=1,t=2,pt=0,l=1,sg=0,st=ok:0
V_LIGHT received: 0
read: 0-0-254 s=1,c=1,t=2,pt=0,l=1,sg=0:1
send: 254-254-0-0 s=1,c=1,t=2,pt=0,l=1,sg=0,st=ok:1
V_LIGHT received: 1
read: 0-0-254 s=1,c=1,t=3,pt=0,l=2,sg=0:43
send: 254-254-0-0 s=1,c=1,t=3,pt=0,l=2,sg=0,st=ok:43
V_DIMMER received: 43
read: 0-0-254 s=1,c=1,t=3,pt=0,l=2,sg=0:86
send: 254-254-0-0 s=1,c=1,t=3,pt=0,l=2,sg=0,st=ok:86
V_DIMMER received: 86
read: 0-0-254 s=1,c=1,t=3,pt=0,l=3,sg=0:100
send: 254-254-0-0 s=1,c=1,t=3,pt=0,l=3,sg=0,st=ok:100
V_DIMMER received: 100
All perfect
Sketch:
// Enable debug prints
#define MY_DEBUG
// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
#define MY_NODE_ID 254
#include <SPI.h>
#include <MySensor.h>
#define SN "DimmableLED /w button"
#define SV "1.2"
#define CHILD_ID_LIGHT 1
MyMessage dimmerMsg(CHILD_ID_LIGHT, V_DIMMER);
void setup()
{
Serial.println("Ready to receive messages...");
}
void presentation() {
// Send the Sketch Version Information to the Gateway
present(CHILD_ID_LIGHT, S_DIMMER);
sendSketchInfo(SN, SV);
}
void loop()
{
}
void receive(const MyMessage &message)
{
if (message.type == V_LIGHT) {
Serial.print("V_LIGHT received: ");
Serial.println(message.getString());
} else if (message.type == V_DIMMER) {
Serial.print("V_DIMMER received: ");
Serial.println(message.getString());
}
else {
Serial.print("Unhandled message received: ");
Serial.println(message.getString());
}
}
The distance sensor is supported in the beta version of Domoticz
Questions (Sorry)
I have rebuild the whole original MQTT sketch so it supports the standard mysensors protocol (the serial/ethernet gateway).
With this, we have all functionality that the original mysensor serial gateway supports.
What would be the downside with this implementation ?
The data being transferred is like
http://www.mysensors.org/download/serial_api_14
It is now also very easy to pass the payload an internal serial/ethernet gateway handler, but the payload is not easily interpreted as human text of course.
Would this be something to submit as a replacement of the original MQTT library?
Devs just need to push the payload to their original serial/ethernet handler, and sending messages is also in the same format
Dont think this is very nice to RFXCom dont you think?
Besides, that you can decode a 'few' protocols, do you really think you can decode all that RFXCom does?
What is expensive ? 100 euro's for a rock solid (and active developed) device ?
Did you looked at the 'RFLink' project?
it might be that this line
gw.present(sensor, V_LIGHT);
should be changed to
gw.present(sensor, S_LIGHT);
I think the comment in the routine
void measureBattery() {
// R1 = 1MOhm, R2 = 220 kOhm
Should be
void measureBattery() {
// R3 = 1MOhm, R2 = 220 kOhm
(R3)
Is it possible to add (comment out) some lines how to calculate the battery percentage and send this via gw.sendBatteryLevel (batteryPcnt)
Great sketch!
Posted a new beta of domoticz.
Lots have been changed
If anyone can supply me with serial log messages of:
S_LIGHT_LEVEL
S_WATT
S_KWH
That would be helpfull
With regards,
Rob
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:
I can not watch this forum, if you want to contribute, plz use the domoticz forum