Hi @maglo18 i have been using a current only version of emon for quite some time, i am interested in adding the ac-ac transformer to calculate the apparent power more accurately. Do you have a project page for your build with diagrams and specs? What type of transformers are you using (i can just about read it from picture) and how happy are you with the performance?
Thanks Gambituk
@tomkxy Any updates to this? my setup has been running well for a long time, but i am itchy to see if it will survive with 1.5.. i know i should just leave it alone 
but i cannot help but tinker with it.
I've been using a version of the mqtt gateway for about 6 months, i setup the LED's like it shows in the advanced build, and they all (3) run with on all the time, and off when activated, i assumed at the time that this was by design, and it's quite nice to have a clear visual indication that things are all ok, with the occasional blink when there is a message received. i quite like it now. my file was compiled with version 1.4.1 modified library. but i believe it was the same behavior with 1.4 also.
Just incase it helps.
Sorry, that's the one step i didn't do, i already had a Rpi, so i started from this step, but i think they should all be somewhat similar, maybe someone else has tried something but i can't offer any genuine advice.
@Sparkman (My last ping for tonight i promise 
)
sensor started, id 22
send: 22-22-25-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4
send: 22-22-25-0 s=255,c=3,t=6,pt=1,l=1,st=fail:25
send: 22-22-25-0 s=255,c=3,t=11,pt=0,l=12,st=ok:Power Sensor
send: 22-22-25-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 22-22-25-0 s=0,c=0,t=13,pt=0,l=3,st=ok:1.4
send: 22-22-25-0 s=0,c=1,t=17,pt=2,l=2,st=ok:9278
send: 22-22-25-0 s=0,c=1,t=17,pt=2,l=2,st=ok:40
send: 22-22-25-0 s=0,c=1,t=17,pt=2,l=2,st=ok:39
send: 22-22-25-0 s=0,c=1,t=17,pt=2,l=2,s
Or just 4 minutes later 
then deleted again the eeprom and then this
send: 22-22-255-255 s=255,c=3,t=7,pt=0,l=0,st=fail:
read: 25-25-22 s=255,c=3,t=8,pt=1,l=1:1
new parent=25, d=2
read: 0-0-22 s=255,c=3,t=8,pt=1,l=1:0
new parent=0, d=1
sensor started, id 22
send: 22-22-0-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4
send: 22-22-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
read: 0-0-22 s=255,c=3,t=6,pt=0,l=1:M
send: 22-22-0-0 s=255,c=3,t=11,pt=0,l=12,st=ok:Power Sensor
send: 22-22-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 22-22-0-0 s=0,c=0,t=13,pt=0,l=3,st=ok:1.4
send: 22-22-0-0 s=0,c=1,t=17,pt=2,l=2,st=ok:9278
I noticed looking above at what i've already posted that this could be an issue with nodes relaying data (or not).. it seems that at some point it decides that another node (25) will be used (it's about half way to gateway and very customised code) but this doesn't seem to be passing the message on.
So i will also try to stop this node from offering its relaying services..
Is there any way to insist that the node only speaks directly to the GW?
thanks in advance
@Sparkman Thanks, so i've just tried resetting to auto, and i was assigned a new value of 22, so i've then set this to a static value in my sketch and re-uploaded it to the nano, so i will test like this, and report back in a day or two ( or hopefully several weeks!).. after that i will experiment with commenting out the library and continue troubleshooting in this direction.
I did notice 1 more anomalie, in that my first reading after the presentation seems to be a value in watts of about 9000, and then after that i have normal and consistant readings from 100 - 4000 depending on whats running in the house.. so i was considering if something in my sketch logic is running wild on the first loops before the state of lastsend timer is valid... or something more.. but that's just an observation.
Thanks again.
Gambit
thanks for the reply @Sparkman , i had looked at that before posting but i can't seem to get my head around what i am supposed to do.... so for example i should erase.. then leave as auto so that it is assigned a value.. and then i can go back to my original static? or should i hard code the value that the controller gives me? (which isn't a major problem...)
Also any idea's for the reason for the actual crash?
Thanks
Gamb
Cloud is probably easiest to get started.. and then depending what you have available you could try mosquitto on windows as a test, assuming you have a windows box already running and then when you are happy with that and understand what is going on then i would suggest investing in something like a raspberry pi so you can have an always on broker on your home network...
I am running mosquito on a Rpi b+ without issues, and also openhab running on the same device, and a mysensors mqtt gateway and several sensor nodes for temp and a power meter that i am working on getting going.
Don't know if that helps.
Gambituk
Hello, i have recently returned to an old project i was working on 6 or more months ago, i modified a sketch to provide current only power readings from ct sensor only measuring current from sensor * typical 230v to get a power reading. It works fine except for the fact that it typically crashes after 1.5 days - 2 days.
So that's issue 1, issue 2 is that after the crash i cant seem to reestablish comms with GW unless i erase eeprom and start again. ( i am also assigning a static node id in sketch)
So my Sketch: (based on mysensors with open energy mteter lib)
#include <SPI.h>
#include <MySensor.h>
#include "EmonLib.h" // Include Emon Library
#define CHILD_ID_POWER 0
#define POWER_SENSOR_ANALOG_PIN 0
#include "EmonLib.h" // Include Emon Library
EnergyMonitor emon1; // Create an instance
unsigned long SLEEP_TIME = 15000; // Sleep time between reads (in milliseconds)
MySensor gw;
MyMessage msg(CHILD_ID_POWER, V_WATT);
int lastwatt;
void setup()
{
emon1.current(2, 60.2); // Current: input pin, calibration. 2 = A2
gw.begin(NULL,27,false);
// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Power Sensor", "1.0");
// Register all sensors to gateway (they will be created as child devices)
gw.present(CHILD_ID_POWER, S_POWER);/////???????????????
}
void loop()
{
static unsigned long lastUpdate;
if (millis() - lastUpdate >= SLEEP_TIME) // If the current time - the last time we updated >= #SLEEP_TIME THEN:
{
double Irms = emon1.calcIrms(1480); // Calculate Irms only
int watt = (Irms*230.0);
// Serial.println(watt);
//if (POWERLevel != lastPOWERPOWERLevel) {
gw.send(msg.set(watt));
// lastPOWERLevel = POWERLevel;
//}
// gw.sleep(SLEEP_TIME);
lastUpdate += SLEEP_TIME; // Last update = lastupdate + SLEEP_TIME
}
}
and my ?presentation data? after failure..
sensor started, id 27
send: 27-27-25-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4
send: 27-27-25-0 s=255,c=3,t=6,pt=1,l=1,st=fail:25
send: 27-27-25-0 s=255,c=3,t=11,pt=0,l=12,st=ok:Power Sensor
send: 27-27-25-0 s=255,c=3,t=12,pt=0,l=3,st=fail:1.0
send: 27-27-25-0 s=0,c=0,t=13,pt=0,l=3,st=ok:1.4
It seems!! as though i can restart as many times as i want until the "failure" with no issues in rebooting and reconnecting, but then something seems to happen during the failure to make in impossible to reconnect without eeprom flash..
and then after erase i have this.
sensor started, id 27
send: 27-27-0-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4
send: 27-27-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
send: 27-27-0-0 s=255,c=3,t=11,pt=0,l=12,st=ok:Power Sensor
send: 27-27-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 27-27-0-0 s=0,c=0,t=13,pt=0,l=3,st=ok:1.4
Please any ideas..??
I'm using codebender to uplaod and several different versions of the arduino ide over the last year but i never really had the time to ask for help here before now, i just got frustrated and turned it off for a while!.. I've also used several different power supplys with all good quality and decent 1A max. I am using also several different nano's as my arduino of choice. .. please help !! 
Group all
Group node1 (all)
Group node2 (all)
Group sketch (all)
Number node1_light "Light Level" (node1,all) {mqtt="<[mysensor:MyMQTT/20/0/V_LIGHT_LEVEL:state:default]"}
Try changing the first line of items like this above.. and in sitemap change node1_temp to node1_light
Also see if activating any of the switches in openhab publishes to myMQTT ?
@C.r.a.z.y. it sounds like he is getting as far as the mqtt broker, so the gateway must be working. ?
mosquitto_sub -h localhost -v -t '#'
This is what i use to see what is happening on mqtt broker, i am using a raspberry pi and mosquitto installed on the same pi. you can also swap localhost for ip address ie 192.168.0.5 etc
can you also please paste a sample of what you see in myMQTT or screenshot maybe? or it can be easier to copy and paste from a terminal window? are you using raspberry pi or something else?
Maybe if you can share your items, sitemap, and rules if any.
Hi, i would be interested in any more updates along this line. In my case my gateway is mostly stable as far as i can tell. several weeks without issues. My problem is that most of my nodes seem to lockup, so i would be totally interested in making them more robust either by software or if necessary with external chip as overlord watchdog
@nutcracker I think the best way to test the function of this battery pack would be to test it using it's designed purpose. So i suggest connecting a heavier load, (for example a smartphone) and see if it also turns off after the same time. or if as you (and I) suppose it stays on because of the extra current draw.
I also have a battery backup system for my phone and it turns off if the current draw drops below a certain level so as to stop my phone from trickle charging after it reaches 100%. (it has a button to start the charging function, it doesn't charge when i just connect the phone.)
Hope this helps.
Initial tests seem that it is now resolved with the fixed version of the mqttclient gateway as modified by fotofieber
http://forum.mysensors.org/topic/524/mqtt-client-gateway/29 There is a proposed solution in the following post, i will test and see if it helps, and report back.
@FotoFieber @ntruchsess i have a parallel post regarding this version of the controller, i did not know it was the same as this one when i opened the thread 
but i am having some garbage issues, do you think this is the same problem as you have described 2 posts up? http://forum.mysensors.org/topic/921/strange-value-being-sent-from-controller-using-mixed-temp-relay-node thanks for any comments or pointers
Thanks @celonunes I eventually found that version of gateway via somebody else. i have another post with some issues i found with that version. http://forum.mysensors.org/topic/921/strange-value-being-sent-from-controller-using-mixed-temp-relay-node it's not really resolved, but i have some kind of workaround.
What i think happens.. in my own way of thinking!
1 2 3 4 5 6 7 8
B a d v a l u e something longer than expected
1 1 . 4 v a l u e next value is 11.4 but longer value stays in a register somewhere
2 1 . 6 5 7 l u e and is mixed with the next value -
1 2 . 5 5 7 l u e until restart or overwrite -
So i think there is something that needs to be changed to control the length of expected values or actual values to adapt to whatever data arrives.
For my workaround, send 1.0 and 0.0 instead of 1 and 0 seems to force the sketch to round the value to 1 or 0 even when there is "1.0dvalue" as the received instruction.
Sorry, i just saw this, do you still have the issue or is it resolved?
That's perfect, that shows clearly that the problem is coming from the gateway sketch. I assume that the r on the end of both your and my output's is a termination character, and everything between the (1/0) and the 'r' in the gateway serial output is 'debris' left over from a previous output.. (for me a previous temp reading, for you something ending in 'so' .
With my workaround from yesterday:- (publishing something like this from openhab or wherever mysensor:MyMQTT/25/4/V_LIGHT:command:ON:1.0r <-1.0r instead of just 1) , my relay reacts really fast and accurately when triggered and continues to work. Before it was very slow and not reliable.
I am not sure if i will find the cause and be able to correct it but at least there is a workaround.
Thanks for your time @gadu
Thanks! That would be really useful
ah, sorry, @gadu i dont think i explained clearly... what i wanted to see was what happens in the serial monitor on the gateway when those values are published (what gets sent over nrf to the node). thanks for trying that, i understand if you cant get serial monitor output. but if it was possible, i would really appreciate it
Ok, well i guess you were listed on the sketch from before it was branched, but thanks for replying.
As an update to my struggles 
i have found a workaround which might hint at a solution..
If i publish :
MyMQTT/25/5/V_LIGHT 0.0r
MyMQTT/25/5/V_LIGHT 1.0r
instead of
MyMQTT/25/5/V_LIGHT 0
MyMQTT/25/5/V_LIGHT 1
Then it seems that it overwrites the scraps of the previous temp readings that are causing trouble, and activates the relay everytime.
also.. interestingly if i publish 0.00r to my mqtt, then the gateway reads all the following temps with a trailing 0 eg 21.90 instead of 21.9 / or '1.9rr' instead of '1.9r' so it seems like it is storing a value somewhere and only overwriting the parts that are conflicting with the next received value.
// NOTE above : Beware to check if there is any length on payload in your incommingMessage code:
// Example: if (msg.type==V_LIGHT && strlen(msg.getString())>0) otherwise the code might do strange things.
I have a question regarding this line in MyMQTTClient.h that perhaps @hek or @ntruchsess might be able to comment on, Is the above issue that i am seeing linked to this warning? it is beyond my weak coding to grasp the implications... Or anyone who may have a comment, i would really love to get this to work!!!
I cannot see where the issue is coming from, the mqttgateway seems very straightforward, i think the answer might be in the libraries or some kind of conflict with the datatypes? it's a little over my head, but i would really love to get this working. 
+1 for me too, it just seems to naturally occur that this should be a feature in this workflow, i guess there could be long ways of going about this with led's and light sensors to actually check and report back the actual situation via mqtt and even a retry rule in openhab, but i would hope there would be a software only way of doing this.
@gadu if you have a setup running, could you publish a message on your mosquitto server just like this?
MyMQTT/25/1/V_LIGHT 1
MyMQTT/25/1/V_LIGHT 0
I don't think it matters if you have any relays connected or defined, it's just to see what value it tries to send to the node... (assuming you have your gateway connected to a pc to be able to see the serial output)?
No problems if this is not possible.
@BulldogLowell I just tried uploading a standard vanilla relay node, and i get the same garbled data instead of 1 and 0 (should have tried this at the start, but i am happy with what i have learned in the last 12 hours.) So it seems almost certain that it is an issue with the @gadu version of the mqtt gateway.. which is unaltered from the above post. #2 above
// Running DS temperature sensor(s) and relay(s) on one mysensor arduino node
// Combines Onewire and Relay code
// 2014-10-14 Pego: Tested and Running on Uno/Clone and MQTT gateway
// Example sketch showing how to send in OneWire temperature readings
// Example sketch showing how to control physical relays.
// This example will remember relay state even after power failure.
#include <MySensor.h>
#include <SPI.h>
#include <DallasTemperature.h>
#include <OneWire.h>
#define ONE_WIRE_BUS 3 // Pin where dallas sensor is connected
#define MAX_ATTACHED_DS18B20 16
#define RELAY_1 4 // Arduino Digital I/O pin number for first relay (second on pin+1 etc)
#define NUMBER_OF_RELAYS 2 // Total number of attached relays
#define RELAY_ON 1 // GPIO value to write to turn on attached relay
#define RELAY_OFF 0 // GPIO value to write to turn off attached relay
#define NUMBER_OF_TEMP_SENSORS 3
unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds) 30000 orig
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
MySensor gw;
float lastTemperature[MAX_ATTACHED_DS18B20];
//int numSensors = 0;
boolean receivedConfig = false;
boolean metric = true;
// Initialize temperature message
MyMessage msg(0, V_TEMP);
//int offsetforrelays = 5;
void setup()
{
// Startup OneWire
sensors.begin();
gw.begin(incomingMessage, AUTO, true); // Startup and initialize MySensors library. Set callback for incoming messages.
gw.sendSketchInfo("Temp and Relays", "1.0"); // Send the sketch version information to the gateway and Controller
for (int i = 0; i < NUMBER_OF_TEMP_SENSORS ; i++)
{
gw.present(i, V_TEMP); // creates 0, 1 and 2
}
for (int sensor = 1, pin = RELAY_1 ; sensor <= NUMBER_OF_RELAYS ; sensor++ , pin++)
// loop from sensor1/pin4 to sensor2/pin5 (numofrelays=2)
{
gw.present(NUMBER_OF_TEMP_SENSORS + sensor, S_LIGHT); // should create 3 and 4
pinMode(pin, OUTPUT);
digitalWrite(pin, gw.loadState(sensor) ? RELAY_ON : RELAY_OFF);
}
}
void loop()
{
// Process incoming messages (like config from server)
gw.process();
// Fetch temperatures from Dallas sensors
sensors.requestTemperatures();
// Read temperatures and send them to controller
for (int i = 0; i < NUMBER_OF_TEMP_SENSORS && i < MAX_ATTACHED_DS18B20; i++) {
// Fetch and round temperature to one decimal
float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric ? sensors.getTempCByIndex(i) : sensors.getTempFByIndex(i)) * 10.)) / 10.;
// Only send data if temperature has changed more then 1 degC and no error
if (int(lastTemperature[i]) != int(temperature) && temperature != -127.00) { //added integer
// Send in the new temperature
gw.send(msg.setSensor(i).set(temperature, 1));
lastTemperature[i] = temperature;
}
}
//gw.sleep(SLEEP_TIME); //no sleep for relays!!!!
}
void incomingMessage(const MyMessage &message) {
// We only expect one type of message from controller. But we better check anyway.
if (message.type == V_LIGHT) {
// Change relay state
Serial.print("Incoming change for sensor:");
Serial.println(message.sensor);
digitalWrite(message.sensor - 4 + RELAY_1, message.getBool() ? RELAY_ON : RELAY_OFF);
// Store state in eeprom
gw.saveState(message.sensor, message.getBool());
// Write some debug info
Serial.print("Incoming change for sensor:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println(message.getBool());
}
}for (int sensor=1, pin=RELAY_1 ; sensor <= NUMBER_OF_RELAYS ; sensor++ , pin++)
{
gw.present(NUMBER_OF_TEMP_SENSORS + sensor, S_LIGHT); // should create 3 and 4
For the earlier part, should this be "for (int sensor=0" to get 3 and 4?
I get 4 and 5 ... But either way, i dont suppose it matters that there is a gap of 1 in the sensor child id's.
I change the callback to this:
digitalWrite(message.sensor - 4 + RELAY_1, message.getBool() ? RELAY_ON : RELAY_OFF);
and that works.... i can send a message and it activates the relay..
BUT....
repeater started, id 25
send: 25-25-0-0 s=255,c=0,t=18,pt=0,l=5,st=ok:1.4.1
send: 25-25-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
read: 0-0-25 s=255,c=3,t=6,pt=0,l=1:M
send: 25-25-0-0 s=255,c=3,t=11,pt=0,l=15,st=ok:Temp and Relays
send: 25-25-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 25-25-0-0 s=0,c=0,t=0,pt=0,l=5,st=ok:1.4.1
send: 25-25-0-0 s=1,c=0,t=0,pt=0,l=5,st=ok:1.4.1
send: 25-25-0-0 s=2,c=0,t=0,pt=0,l=5,st=ok:1.4.1
send: 25-25-0-0 s=4,c=0,t=3,pt=0,l=5,st=ok:1.4.1
send: 25-25-0-0 s=5,c=0,t=3,pt=0,l=5,st=ok:1.4.1
send: 25-25-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:19.1
Here i am sending a message with 1 and then 0 to relay id4 and then the same to relay id5 -It works, but i still have the 1.3 and 0.3 values
read: 0-0-25 s=5,c=1,t=2,pt=0,l=4:1.3r
Incoming change for sensor:5
Incoming change for sensor:5, New status: 1
read: 0-0-25 s=5,c=1,t=2,pt=0,l=4:0.3r
Incoming change for sensor:5
Incoming change for sensor:5, New status: 0
And then it starts going even crazier, only seeing the status as 1 and received command is nothing like boolean so it see's 0's and 1's as only 1's
read: 0-0-25 s=4,c=1,t=2,pt=0,l=4:1.3r
Incoming change for sensor:4
Incoming change for sensor:4, New status: 1
read: 0-0-25 s=4,c=1,t=2,pt=0,l=4:0.3r
Incoming change for sensor:4
Incoming change for sensor:5, New status: 1
read: 0-0-25 s=5,c=1,t=2,pt=0,l=4:003r
Incoming change for sensor:5
Incoming change for sensor:5, New status: 1
read: 0-0-25 s=5,c=1,t=2,pt=0,l=4:003r
Incoming change for sensor:5
Incoming change for sensor:5, New status: 1
read: 0-0-25 s=5,c=1,t=2,pt=0,l=4:013r
Incoming change for sensor:5
Incoming change for sensor:5, New status: 1
read: 0-0-25 s=4,c=1,t=2,pt=0,l=4:113r
Incoming change for sensor:4
Incoming change for sensor:4, New status: 1
read: 0-0-25 s=4,c=1,t=2,pt=0,l=4:013r
Incoming change for sensor:4
Incoming change for sensor:4, New status: 1
Any ideas
0;0;3;0;9;read: 25-25-0 s=0,c=0,t=0,pt=0,l=5:1.4.1
0;0;3;0;9;read: 25-25-0 s=1,c=0,t=0,pt=0,l=5:1.4.1
0;0;3;0;9;read: 25-25-0 s=2,c=0,t=0,pt=0,l=5:1.4.1
0;0;3;0;9;read: 25-25-0 s=4,c=0,t=3,pt=0,l=5:1.4.1
0;0;3;0;9;read: 25-25-0 s=5,c=0,t=3,pt=0,l=5:1.4.1
So far it seems to create 0,1,2,4,5 but i think that's not going to be a problem, just working my way through to figure what else i need to change for the callback? (and what a callback is )
Thanks for the help so far!
no, i took it out (without effect) about an hour ago
I tried to modify the temp child presentation like this..... but it seemed to have no effect
int offsetforrelays=5; //(at start of sketch)
// and this further down in the presentation for temp sensors
for (int i=0; i<(numSensors+offsetforrelays) && i<(MAX_ATTACHED_DS18B20+offsetforrelays) && i>offsetforrelays; i++) {
gw.present(i, V_TEMP);
}
but so far it hasn't assigned any different id's to the temp sensors. Anyone got any pointers?
was thinking of presenting the temps sensors first, and adding something like && i>NUMBER_OF_RELAYS to start assigining child id's above the range of relays? Will test and report back
Hi, i have 3 temp sensors and 2 relays, I am just looking at how to make this work but am not making much progress. Cant figure out how to assign the child id's. Any help would be appreciated.
No it seems like they are given the same child id's. Ok, so maybe i'l look at how to force a different child id for each sensor/actuator
I guess this probably should have been in troubleshooting :S
I've seen this 85 degree value on the DS18B20's as well. I would assume it's common to the whole range, i normally solve this with a sensors begin call followed by a delay in the setup loop, but this addition would be a good add to the sketch imho !
and here is the modified relay/temp sketch
// Running DS temperature sensor(s) and relay(s) on one mysensor arduino node
// Combines Onewire and Relay code
// 2014-10-14 Pego: Tested and Running on Uno/Clone and MQTT gateway
// Example sketch showing how to send in OneWire temperature readings
// Example sketch showing how to control physical relays.
// This example will remember relay state even after power failure.
#include <MySensor.h>
#include <SPI.h>
#include <DallasTemperature.h>
#include <OneWire.h>presen
#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected
#define MAX_ATTACHED_DS18B20 16
#define RELAY_1 4 // Arduino Digital I/O pin number for first relay (second on pin+1 etc)
#define NUMBER_OF_RELAYS 2 // Total number of attached relays
#define RELAY_ON 1 // GPIO value to write to turn on attached relay
#define RELAY_OFF 0 // GPIO value to write to turn off attached relay
unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds) 30000 orig
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
MySensor gw;
float lastTemperature[MAX_ATTACHED_DS18B20];
int numSensors=0;
boolean receivedConfig = false;
boolean metric = true;
// Initialize temperature message
MyMessage msg(0,V_TEMP);
void setup()
{
// Startup OneWire
sensors.begin();
// Startup and initialize MySensors library. Set callback for incoming messages.
//gw.begin();
gw.begin(incomingMessage, AUTO, true);
// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Temp and Relays", "1.0");
// Fetch the number of attached temperature sensors
numSensors = sensors.getDeviceCount();
// Present all sensors to controller
for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
gw.present(i, V_TEMP);
}
// Fetch relay status
for (int sensor=1, pin=RELAY_1; sensor<=NUMBER_OF_RELAYS;sensor++, pin++) {
// Register all sensors to gw (they will be created as child devices)
gw.present(sensor, S_LIGHT);
// Then set relay pins in output mode
pinMode(pin, OUTPUT);
// Set relay to last known state (using eeprom storage)
digitalWrite(pin, gw.loadState(sensor)?RELAY_ON:RELAY_OFF);
}
}
void loop()
{
// Process incoming messages (like config from server)
gw.process();
// Fetch temperatures from Dallas sensors
sensors.requestTemperatures();
// Read temperatures and send them to controller
for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
// Fetch and round temperature to one decimal
float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
// Only send data if temperature has changed more then 1 degC and no error
if (int(lastTemperature[i]) != int(temperature) && temperature != -127.00) { //added integer
// Send in the new temperature
gw.send(msg.setSensor(i).set(temperature,1));
lastTemperature[i]=temperature;
}
}
//gw.sleep(SLEEP_TIME); //no sleep for relays!!!!
}
void incomingMessage(const MyMessage &message) {
// We only expect one type of message from controller. But we better check anyway.
if (message.type==V_LIGHT) {
// Change relay state
digitalWrite(message.sensor-1+RELAY_1, message.getBool()?RELAY_ON:RELAY_OFF);
// Store state in eeprom
gw.saveState(message.sensor, message.getBool());
// Write some debug info
Serial.print("Incoming change for sensor:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println(message.getBool());
}
}For ease of access here is the mqtt gateway sketch with the intro comments removed for pasting here,
#include <SPI.h>
#include <MySensor.h>
#include "MyMQTTClient.h"
#include "PubSubClient.h"
#include <Ethernet.h>
/*
* To configure MQTTClientGateway.ino to use an ENC28J60 based board include
* 'UIPEthernet.h' (SPI.h required for MySensors anyway). The UIPEthernet-library can be downloaded
* from: https://github.com/ntruchsess/arduino_uip
*/
//#include <UIPEthernet.h>
/*
* To execute MQTTClientGateway.ino on Yun uncomment Bridge.h and YunClient.h.
* Do not include Ethernet.h or SPI.h in this case.
* On Yun there's no need to configure local_ip and mac in the sketch
* as this is configured on the linux-side of Yun.
*/
//#include <Bridge.h>
//#include <YunClient.h>
// * Use this for IBOARD modded to use standard MISO/MOSI/SCK, see note *1 above!
/*
#define RADIO_CE_PIN 3 // radio chip enable
#define RADIO_SPI_SS_PIN 8 // radio SPI serial select
#define RADIO_ERROR_LED_PIN A2 // Error led pin
#define RADIO_RX_LED_PIN A1 // Receive led pin
#define RADIO_TX_LED_PIN A0 // the PCB, on board LED*/
// * Use this for default configured pro mini / nano etc :
///*
#define RADIO_CE_PIN 7 // radio chip enable
#define RADIO_SPI_SS_PIN 8 // radio SPI serial select
#define RADIO_ERROR_LED_PIN 5 // Error led pin
#define RADIO_RX_LED_PIN 6 // Receive led pin
#define RADIO_TX_LED_PIN 9 // the PCB, on board LED*/
//replace with ip of server you want to connect to, comment out if using 'remote_host'
uint8_t remote_ip[] =
{ 192, 168, 0, 7 };
//replace with hostname of server you want to connect to, comment out if using 'remote_ip'
//char* remote_ip = "server.local";
//replace with the port that your server is listening on
#define remote_port 1883
//replace with arduinos ip-address. Comment out if Ethernet-startup should use dhcp. Is ignored on Yun
uint8_t local_ip[] = {192,168,0,10};
//replace with ethernet shield mac. It's mandatory every device is assigned a unique mac. Is ignored on Yun
uint8_t mac[] =
{ 0x90, 0xA2, 0xDA, 0x0D, 0x07, 0x02 };
//////////////////////////////////////////////////////////////////
#if defined remote_ip && defined remote_host
#error "cannot define both remote_ip and remote_host at the same time!"
#endif
#ifdef _YUN_CLIENT_H_
YunClient ethClient;
#else
EthernetClient ethClient;
#endif
void
processMQTTMessages(char* topic, byte* payload, unsigned int length);
PubSubClient client(remote_ip, remote_port, processMQTTMessages, ethClient);
MyMQTTClient gw(client,RADIO_CE_PIN, RADIO_SPI_SS_PIN);
void
setup()
{
Ethernet.begin(mac, local_ip);
delay(1000); // Wait for Ethernet to get configured.
gw.begin(RF24_PA_LEVEL_GW, RF24_CHANNEL, RF24_DATARATE,
RADIO_RX_LED_PIN, RADIO_TX_LED_PIN, RADIO_ERROR_LED_PIN);
}
void
loop()
{
if (!client.connected())
{
client.connect("mysensor");
client.subscribe("MyMQTT/#");
}
client.loop();
gw.processRadioMessage();
}
void
processMQTTMessages(char* topic, byte* payload, unsigned int length)
{
gw.processMQTTMessage(topic, payload, length);
}Hello, I am getting strange values being sent from this controller sketch from @gadu (many thanks again) and this node sketch from @pgo
It almost works.. i am going via mosquitto install on the same raspberry as openhab, and it does turn on and off the relay while sending temp values from the same node. The problem i am having is that it is not reliable, it doesn't always turn on and off, and i have found that the following is being sent from the mqtt gateway sketch:
0;0;3;0;9;send: 0-0-21-21 s=0,c=1,t=0,pt=0,l=5,st=ok:19.7r
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5:5.4
publish: MyMQTT/21/1/V_TEMP 5.4
0;0;3;0;9;send: 0-0-21-21 s=1,c=1,t=0,pt=0,l=5,st=fail:5.47r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:147r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:047r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:147r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:047r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:147r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:047r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:147r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:047r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:147r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:047r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:147r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:047r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:147r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:047r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:147r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:047r
0;0;3;0;9;read: 21-21-0 s=0,c=1,t=0,pt=7,l=5:19.8
publish: MyMQTT/21/0/V_TEMP 19.8
0;0;3;0;9;send: 0-0-21-21 s=0,c=1,t=0,pt=0,l=5,st=ok:19.8r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:1.8r
0;0;3;0;9;send: 0-0-24-24 s=2,c=1,t=2,pt=0,l=4,st=ok:0.8r
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5:5.6
publish: MyMQTT/21/1/V_TEMP 5.6
0;0;3;0;9;send: 0-0-21-21 s=1,c=1,t=0,pt=0,l=5,st=fail:5.68r
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5:5.5
so.. node 21 is just sending temp values, node 24 is the mixed temp/relay..
As you may notice the 1 and zero code for the relay is getting mixed with the last received temp values, which seems to be ok if the last temp read is more than 10degrees resulting in a 1.xx value sent or a 0.xx value sent, which is accepted as a 1 or 0, but when it receives a value below 10 then it converts it to something like 047 or 147 which doesn't trigger the relay correctly! Please any help or guidance to understand where the 1 or 0 message is coming from?
I imagine its what is being sent from the gateway sketch that is mixing the payload, but i cannot see how to reformulate what is sent to send only a 1 or 0 when sending to the relay...... ??
MyMQTT/24/0/V_TEMP 23.9
MyMQTT/21/1/V_TEMP 5.1
MyMQTT/24/2/V_LIGHT 1
MyMQTT/24/2/V_LIGHT 0
MyMQTT/24/2/V_LIGHT 1
=Sample of mqtt messages showing 24 node with v_temp and V_light on node 24 and v_temp on node 21
Hi, any progress with this? I would be interested in trying to adapt this to my needs. I have just finished setting up the basic arduino sketch from http://openenergymonitor.org/emon/buildingblocks/how-to-build-an-arduino-energy-monitor-measuring-current-only
and i assume this should just work with the sketch you are working on?
Just a THANK YOU for @gadu, the info above was exactly what i was looking for. Now i can continue with the rest of my project!! 
I just found that exact same feature... mosquitto_sub -h localhost -v -t '#' or mosquitto_sub -h 192.168.0.7 -v -t '#'
That has totally helped me to see what is going on, and i can now see that openHAB section is working. but from the MQTTGateway sketch from the build page i get only something like this..
connecting at 115200
Started!
0;0;3;0;9;read: 25-25-0 s=0,c=1,t=0,pt=7,l=5:23.4
0;0;3;0;9;read: 25-25-0 s=0,c=1,t=0,pt=7,l=5:22.1
0;0;3;0;9;read: 25-25-0 s=0,c=1,t=0,pt=7,l=5:21.4
0;0;3;0;9;read: 25-25-0 s=0,c=1,t=0,pt=7,l=5:21.0
0;0;3;0;9;read: 25-25-0 s=0,c=1,t=0,pt=7,l=5:20.8
0;0;3;0;9;read: 25-25-0 s=0,c=1,t=0,pt=7,l=5:20.6
Should there be something happening to publish to mqtt? i kinda thought that was the point of this type of GW?
Thanks again for all the help so far. I can try to do a tutorial when i am finished from my noob perspective that might be useful for others.
AH! ok. that part seems clear now. Any idea's about the MQTT part? I am really looking for a way to get a handle on what is being sent. Been searching all day (and most of yesterday :/)
Thanks again,
Hello. I am trying to get a connection working with mysensors I have the two devices communicating, but in order to make smaller steps, i want to assign a static node address to the remote node that is running dallas sketch for temp.
I read in other threads that :
gw.begin(NULL,25,false); is the way to do it.. I have tried two values, 5 and 25.
The serial output from the GW when i am running is like this.
0;0;3;0;9;read: 5-5-0 s=0,c=1,t=0,pt=7,l=5:21.3
0;0;3;0;9;read: 5-5-0 s=0,c=1,t=0,pt=7,l=5:21.2
0;0;3;0;9;read: 5-5-0 s=0,c=1,t=0,pt=7,l=5:21.1
0;0;3;0;9;read: 5-5-0 s=0,c=1,t=0,pt=7,l=5:21.0
0;0;3;0;9;read: 25-25-0 s=255,c=0,t=17,pt=0,l=3:1.4
0;0;3;0;9;read: 25-25-0 s=255,c=3,t=6,pt=1,l=1:0
0;0;3;0;9;read: 25-25-0 s=255,c=3,t=11,pt=0,l=18:Temperature Sensor
0;0;3;0;9;read: 25-25-0 s=255,c=3,t=12,pt=0,l=3:1.0
0;0;3;0;9;read: 25-25-0 s=0,c=0,t=6,pt=0,l=3:1.4
0;0;3;0;9;read: 25-25-0 s=0,c=1,t=0,pt=7,l=5:20.9
0;0;3;0;9;read: 25-25-0 s=0,c=1,t=0,pt=7,l=5:20.8
0;0;3;0;9;read: 25-25-0 s=0,c=1,t=0,pt=7,l=5:20.9
Is the first value after read the node and the second the child?
If this is the case, and i wanted to check what was being sent to openhab via mqtt what would the topic be that i would subscribe to? (for example before i connect to the openHAB controller, i could use myMQTT to view the topic for troubleshooting?)
Thanks for any help
Hello. I am new to Mysensors, openhab and mosquitto.. I have a working knowledge of arduino and nrf24l01, and currently am running a wireless(nrf) twitter controlled heating scheduler, and am sending multiple temp (ds18b20) sensors to Xively feed.
I am really hooked on the idea of mqtt and openhab, and i thought that mysensors seemed like a good solution for implementing that idea.
My progress so far is to install the DallasTemperatureSensor by MySensors node to one nano, and the ethernet gateway sketc as a first step, and now i have installed the mqttgateway again from the build page, and i have a working install of mosquitto and openhab on a rasp pi b+.
I am just having difficulty getting it all stuck together. I have created the sitemap items and transform files as above and can access the openhab sitemap for the above configuration. i just don't know if i need to configure other items? how can i test each step? and can i use mosquitto with the setup that i have outlined. There seems to be conflicting info about what can and cannot be done with mosquitto and mysensors.
1 do i need to modify the sketch of the temp node? i have some output from the serial that suggests that it is communicating with the gateway.
2 do i need to modify the gateway with info of the mosquitto server?
3 what can i do to test each step of the transit from temp sensor to openhab?
Thanks for any and all responses.