Thanks for the suggestion, this is so far I have come as well. That is, I will use a regular moteino connected to a raspberry pi that I connect to the network in the barn. If I give it a separate network ID it should not be in conflict with what I use inside my house, and I believe that domoticz should have no issues with to different mysensors gateways connected. Lucky I installed broadband in my barn just last week 
@DavidZH i have thought the same, but that software is an very simple script. Still, you might be right.
Hi,
I upgraded my gateway to the release version 2.0 using a moteino with a rfm69 radio attached. After one or two days the gateway stops responding. It is connected by a 20 cm USB cable directly to my computer. On the computer side I am running the latest version of domoticz which pings the Gateway every 10 seconds or so. since I have issues with connecting to many serial devices I am running it through a serial-socket Gateway script (python) that forwards all data from the socket to the serial port and vice versa. A usual sequence looks like this:
Received socket: 0;0;3;0;18;PING
Received serial: 0;255;3;0;22;23458138
Received serial: 0;255;3;0;9;TSP:SANCHK:OK
When things stop workingit continues sending pings to the Gateway, but no response is received, nor any other messages. It is usually resolved by reconnecting to the serial port, but sometimes I need to physically unplug the device to reset it. Have anyone else experienced such stability issues?
One on my sensors is mounted quite far away with spotty radio coverage. This means that the sensor will not always boot correctly since it is not able to reach the Gateway (apparently the sensor hangs on initialisation while trying to initiate a connection with the Gateway). A radio connection is not critical for me since I have a local interface on the sensor to actuate it and display readings. However, this feature prevents the sensor from operating locally. Is there a way to instruct the library to give up if the initial radio communication fails and work in some kind of "off-line" mode?
I have a generic multi meter, but I was not able to measure the current with this. I'm not sure why, I put it between the battery and the final connection terminal of the battery compartment.
I am not getting frequent reports, so if you are right that means that sleep is working as you suggest. I believe the weather shield is not drawing much power, it is simply a collection of a temperature and humidity sensor, a barometric pressure sensor, and a battery voltage reading circuit which is switched off when not used. More information about this shield is here: http://lowpowerlab.com/blog/2015/01/30/weathershield-is-here/.
Hi guys,
I have a battery-powered moteino with the RFM96 radio and a WeatherShield attached for environment measurements (and for hardware simplicity). I am powering everything from 3 1.5 V AA cells in series.
The node sleeps for 900000 seconds after reading the various sensor measurements from the board (temperature, humidity, pressure, and battery level). I set the node up last night and it lasted for around seven hours before the battery ran out. Apparently it appears not to be sleeping as it should. What am I doing wrong? Sketch is included below.
// Enable debug prints to serial monitor
#define MY_DEBUG
// Enable and select radio type attached
#define MY_RADIO_RFM69
#define MY_IS_RFM69HW
#define MY_RFM69_FREQUENCY RF69_868MHZ
#include <SPI.h>
#include <MySensors.h>
#include <DHT.h>
#include <SFE_BMP180.h> //get it here: https://github.com/LowPowerLab/SFE_BMP180
#include <SI7021.h> //get it here: https://github.com/LowPowerLab/SI7021
#include <Wire.h>
#define REPORT_INTERVAL 900000
#define ALTITUDE 220
#define CHILD_TEMPERATURE 1
#define CHILD_HUMIDITY 2
#define CHILD_PRESSURE 3
#define CHILD_POWER 4
SI7021 sensor;
SFE_BMP180 pressure;
int BATTERY_SENSE_PIN = A7; // select the input pin for the battery sense point
char *weather[] = {"stable", "sunny", "cloudy", "unstable", "thunderstorm", "unknown"};
int minutes;
float pressureSamples[180];
int minuteCount = 0;
bool firstRound = true;
float pressureAvg[7];
float dP_dt;
MyMessage temperatureMessage(CHILD_TEMPERATURE, V_TEMP);
MyMessage humidityMessage(CHILD_HUMIDITY, V_HUM);
MyMessage pressureMessage(CHILD_PRESSURE, V_PRESSURE);
MyMessage forecastMsg(CHILD_PRESSURE, V_FORECAST);
MyMessage powerMessage(CHILD_POWER, V_VOLTAGE);
bool changed = false;
float lastPressure = -1;
float lastTemperature = -1;
float lastHumidity = -1;
int lastForecast = -1;
float lastBattery = -1;
void setup()
{
// use the 1.1 V internal reference
#if defined(__AVR_ATmega2560__)
analogReference(INTERNAL1V1);
#else
analogReference(INTERNAL);
#endif
sensor.begin();
if (pressure.begin())
Serial.println("BMP180 init success");
else
{
// Oops, something went wrong, this is usually a connection problem,
// see the comments at the top of this sketch for the proper connections.
Serial.println("BMP180 init fail\n\n");
//while(1); // Pause forever.
}
}
void presentation() {
// Send the sketch version information to the gateway and Controller
sendSketchInfo("Outdoors environment", "2.0");
// Register all sensors to gateway (they will be created as child devices)
present(CHILD_TEMPERATURE, S_TEMP);
delay(250);
present(CHILD_HUMIDITY, S_HUM);
delay(250);
present(CHILD_PRESSURE, S_BARO);
delay(250);
present(CHILD_POWER, S_POWER);
}
void loop()
{
changed = false;
float temperature = sensor.getCelsiusHundredths() / 100;
int humidity = sensor.getHumidityPercent();
if (lastTemperature != temperature) {
changed = true;
lastTemperature = temperature;
}
if (lastHumidity != humidity) {
changed = true;
lastHumidity = humidity;
}
pinMode(A3, OUTPUT);
digitalWrite(A3, LOW);
lastBattery = analogRead(A7) / 10;
pinMode(A3, INPUT);
#ifdef MY_DEBUG
float batteryV = lastBattery * 0.003363075 * 10;
Serial.print("Battery Voltage: ");
Serial.print(batteryV);
Serial.println(" V");
Serial.print("Battery percent: ");
Serial.print(lastBattery);
Serial.println(" %");
#endif
char status;
double T, P, p0, a;
status = pressure.startTemperature();
if (status != 0)
{
// Wait for the measurement to complete:
delay(status);
// Retrieve the completed temperature measurement:
// Note that the measurement is stored in the variable T.
// Function returns 1 if successful, 0 if failure.
status = pressure.getTemperature(T);
if (status != 0) {
status = pressure.startPressure(3);
if (status != 0)
{
delay(status);
status = pressure.getPressure(P, T);
if (status != 0)
{
p0 = pressure.sealevel(P, ALTITUDE); // we're at 1655 meters (Boulder, CO)
int forecast = 5;//sample(p0);
if (lastPressure != p0) {
changed = true;
lastPressure = p0;
Serial.print("relative (sea-level) pressure: ");
Serial.print(p0, 2);
Serial.print(" mb, ");
}
if (lastForecast != forecast) {
changed = true;
lastForecast = forecast;
}
}
else Serial.println("error retrieving pressure measurement\n");
}
else Serial.println("error starting pressure measurement\n");
}
else Serial.println("error retrieving temperature measurement\n");
}
else Serial.println("error starting temperature measurement\n");
if (changed) {
send(temperatureMessage.set(lastTemperature, 1));
send(pressureMessage.set(lastPressure, 1));
send(humidityMessage.set(lastHumidity, 1));
sendBatteryLevel( lastBattery);
if (lastForecast > -1)
send(forecastMsg.set(weather[lastForecast]));
}
sleep(REPORT_INTERVAL);
}Hello again.
As a temporary fix I found a simple TCP/serial Gateway Python snippet that handles the connection to the serial mysensors device and provides a TCP interface to openhab. Switching the binding of aggression from serial to socket and having it connected to this software gateway removes the core dump issue. This confirms my suspicions that the issues are with the serial port library.
It works okay as a workaround until someone figure something out
If anyone else is having issues with the serial connection, this is the by then snippet I found and used:
https://github.com/pyserial/pyserial/blob/master/examples/tcp_serial_redirect.py
After a full computer crash (overheated CPU, CPU fan stopped working) I'm trying to set everything up on a new computer. Using the latest openhab2 beta 3 I'm having issues with using this binding. Specifically, whenever I add my standard thing configuration I get a buffer overflow in openhab which results in a core dump.
I have downloaded latest binding from the link at github, but that did not affect it. In addition to this binding I am using the zwave binding and rfxcom binding. All three connect to devices through serial ports, although I I'm not sure if they do it in the same way.
You may recall that I have had trouble using these three bindings together earlier, but for some reason things worked out and it has worked quite reliably since then.
I'm not sure which information from the system crash is useful, but if there is anything I can send you to help you figure out what happens, let me know. Also, I realise that this problem might not be related directly with mysensors, but maybe with the serial library used (I saw a reference to NVJavaSeria in the stack trace after the crash.
@mfalkvidd The cable had some kind of repeater on it, and my rfxtrx433 has worked perfectly all the time, even with the MS gateway connected, so I thought the MS gateway should work also 
️
@lafleur I have also updated my local RFM69 library to the latest version with some additional changes to solve issues with acknowledgements not being received. If you're interested, you can see my conclusion here: https://forum.mysensors.org/topic/3663/testing-development-branch-with-rf69hw-is-not-working-as-it-should/12
I also link to a separate thread over at the low-power forum where things are discussed in more detail. If we are planning to upgrade the RFM library I propose that we include the fix I found. The only problem is that this fix is mostly a temporary solution, so perhaps it is better to wait until the issue is fixed in the library itself.
I do not know what happened to the other guy, but for my problems everything was related to the radio not receiving packets correctly when waking from sleep as I described in the thread. After resolving that issue, and switching to a frequency (from 868 to 869) outside of the allowed band because of radio noise my network became quite stable.
I did not post any more to the thread since I had already described my solution that worked :-). I think the problem I'm seeing now is not related to the same thing. My current theory is maybe that my USB cable was too long (15 m) so that the device did not receive enough power. I have moved closer to the computer to see if stability improves.
After finally getting my sensible indication to work quite reliably, I'm experiencing problems with my serial gate on the dev branch as of some weeks ago. It works fine for several days, but at some point it stops responding. Restarting the serial connection is not sufficient, I have to physically unplug it to get it to respond again. I'm not sure if this is a problem with the board or software related? Has anyone else experienced similar issues? I'm using a moteino USB board with the RFM69HW radio.
It seems like my sensors are quite stable, they have not crashed for several weeks of operation.
@andreacioni Sure, getting automatically configured alerts both for silent sensors and low battery for free would be great ️.
@andreacioni This can be easily done with a periodic rule that checks the latest update of the value assuming you have some persistence like rrd configured.
A simple thing you can do in RFM69Transport is to increase the retry count for the messages that are sent. The default value is 2 (implicit), to increase this by changing the following:
return _radio.sendWithRetry(to,data,len);
to
return _radio.sendWithRetry(to,data,len, 5);
To have it retry five times.
My guess is that this will greatly increase the operation time of your network.
@BenCranston For testing the noise I simply print the result from readRSSI() inside the radio library inside the canSend function to the serial connection. The reason for doing it like this is that the radio is very picky about which mode it has to be in for reporting the rssi value. I used the node example from the RFM69 as the basis for this test. At the beginning of RFM69.cpp there are three lines that initialise the radio with the correct frequency. This can be changed to shift the frequency up or down a few megahertz.
I'v never had a chance/need to look into the routing functionality (although I actually have a PhD in network routing), so I cannot comment much on this. From your description the basic problem is that the gateway for some reason fails to respond, or that the response from the gateway is not captured by the node. The resulting routing flood seems like the natural consequence of this. This is why i pointed to the latest developments in my testing since you're better off solving the thing that triggers the rerouting rather than fixing any rerouting problems yourself
@BenCranston I'm glad the fix the proposed helped out, but too bad it was not good enough. It might be worth catching up on the latest few developments in the thread. Basically it turns out that changing all references to standby to sleep in the setMode function is a bit overkill. Maybe this is also causing some of your trouble. The current version of the fix consists of putting the radio to sleep in receiveBegin, like this:
void RFM69::receiveBegin() {
DATALEN = 0;
SENDERID = 0;
TARGETID = 0;
PAYLOADLEN = 0;
ACK_REQUESTED = 0;
ACK_RECEIVED = 0;
RSSI = 0;
setMode(RF69_MODE_SLEEP);
if (readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_PAYLOADREADY)
writeReg(REG_PACKETCONFIG2, (readReg(REG_PACKETCONFIG2) & 0xFB) | RF_PACKET2_RXRESTART); // avoid RX deadlocks
writeReg(REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01); // set DIO0 to "PAYLOADREADY" in receive mode
setMode(RF69_MODE_RX);
}
In my case it also turned out that the RF environment around 868 MHz was a bit noisy. This messed with the CSMA function which always caused the node to wait a second before transmitting the message since the channel was never quiet enough. This limit is controlled by CSMA_LIMIT which I set to -40 instead of -90. Actually, what I ended up doing was to switch the frequency down 1 MHz, to 867, which was a much quieter band. The trouble with the high noise floor was that the gateway had trouble hearing the nodes that were far enough away to have a received RSSI less than -60 when the noise floor was -55. It could be worth continuously printing the RSSI of the channel at the gateway without anyone transmitting to see what your background noise is.
Now that things seem to be working on all levels, I have a very small request. Could someone please update the "baro" thing definition to include "V_PRESSURE" as well as "V_FORECAST"? My arduino is not big enough to calculate the forecast without running out of memory, so I can only send the actual barometric pressure.
Edit: Perhaps it is better to replace forecast with pressure for baro and create a new channel for the forecast?
What would also have been great, but this is a longer shot, would be to have some standardised way of getting received signal strength for the (at least directly connected) sensors. At least the RFM69 has an easy way of reporting RSSI, so just need a standard way of reporting this to the binding. Currently I'm reporting it as a generic debug message like this: 0;255;3;0;9;Received RSSI: -32
The reason I want to keep track of this is to keep an eye on the RF environments around my sensors. Things may change for many reasons (appliances, foliage, et cetera) and this will allow me to pre-emptively correct any problems in the future
I just tried disconnecting and reconnecting the board and restarting OH2 again, and this time it seems to have initialised correctly :-). I'm not sure why it didn't work the first two times, though.
@andreacioni The difference is that I never get a response from the board for some reason. Connecting using screen works without issues. I think the still might be an issue with the serial lock, but given that we actually receive some data at all this might not be the case after all.
Edit: I have rebooted the board by unplugging it and reconnecting it.
I restarted OH2 after changing the configuration, and this time I get no exceptions, but I see no more messages from the binding after the one included below.
@kolaf said:
22:34:40.815 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 0;0;3;0;2;
Edit: after a while I finally received a few packets in the debug console:
2016-04-23 23:10:49.020 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;d0;6t,
2016-04-23 23:10:49.021 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;4;1012.9
Both of the packets seem quite mangled, they are missing pieces, and some of the pieces present do not make sense. I have verified that the baud rate is correct, and when I correct directly to the Gateway using a serial console the output looks normal.
Thanks for the suggestion. I updated the configuration like this:
Bridge mysensors:bridge-ser:gateway [ serialPort="/dev/mysensorsUSB", sendDelay=200, skipStartupCheck=true ] {
baro stableBarometer [ nodeId="6", childId="3" ]
power mainPower [ nodeId="3", childId="1" ]
temperature basementTemperature [ nodeId="10", childId="1"]
}
It did not work as expected. The resulting log is like this:
22:34:35.570 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'mysensors.things'
22:34:35.606 [DEBUG] [col.serial.MySensorsSerialConnection] - Shutting down serial connection!
22:34:35.606 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Stopping Writer thread
22:34:35.606 [DEBUG] [g.mysensors.protocol.MySensorsReader] - Stopping Reader thread
22:34:35.606 [DEBUG] [nsors.handler.MySensorsBridgeHandler] - Initialization of the MySensors Bridge
22:34:35.607 [DEBUG] [col.serial.MySensorsSerialConnection] - Connecting to /dev/mysensorsUSB [baudRate:115200]
22:34:35.614 [DEBUG] [col.serial.MySensorsSerialConnection] - Successfully connected to serial port.
22:34:35.614 [DEBUG] [col.serial.MySensorsSerialConnection] - Waiting 5 seconds to allow correct reset trigger on serial connection opening
22:34:40.608 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while calling thing updated at ThingHandler 'org.openhab.binding.mysensors.handler.MySensorsBridgeHandler@534c4d92: null
java.util.concurrent.TimeoutException
at java.util.concurrent.FutureTask.get(FutureTask.java:205)[:1.8.0_66]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:179)[88:org.eclipse.smarthome.core:0.8.0.201604051458]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:72)[88:org.eclipse.smarthome.core:0.8.0.201604051458]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:56)[88:org.eclipse.smarthome.core:0.8.0.201604051458]
at org.eclipse.smarthome.core.thing.internal.ThingManager.thingUpdated(ThingManager.java:515)[94:org.eclipse.smarthome.core.thing:0.8.0.201604051458]
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyTrackers(ThingRegistryImpl.java:218)[94:org.eclipse.smarthome.core.thing:0.8.0.201604051458]
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyListenersAboutUpdatedElement(ThingRegistryImpl.java:141)[94:org.eclipse.smarthome.core.thing:0.8.0.201604051458]
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyListenersAboutUpdatedElement(ThingRegistryImpl.java:1)[94:org.eclipse.smarthome.core.thing:0.8.0.201604051458]
at org.eclipse.smarthome.core.common.registry.AbstractRegistry.updated(AbstractRegistry.java:102)[88:org.eclipse.smarthome.core:0.8.0.201604051458]
at org.eclipse.smarthome.core.common.registry.AbstractProvider.notifyListeners(AbstractProvider.java:57)[88:org.eclipse.smarthome.core:0.8.0.201604051458]
at org.eclipse.smarthome.core.common.registry.AbstractProvider.notifyListenersAboutUpdatedElement(AbstractProvider.java:82)[88:org.eclipse.smarthome.core:0.8.0.201604051458]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.access$3(GenericThingProvider.java:1)[118:org.eclipse.smarthome.model.thing:0.8.0.201604051458]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider$18.apply(GenericThingProvider.java:700)[118:org.eclipse.smarthome.model.thing:0.8.0.201604051458]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider$18.apply(GenericThingProvider.java:1)[118:org.eclipse.smarthome.model.thing:0.8.0.201604051458]
at org.eclipse.xtext.xbase.lib.IterableExtensions.forEach(IterableExtensions.java:399)[129:org.eclipse.xtext.xbase.lib:2.6.2.v201407030533]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.modelChanged(GenericThingProvider.java:705)[118:org.eclipse.smarthome.model.thing:0.8.0.201604051458]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:200)[107:org.eclipse.smarthome.model.core:0.8.0.201604051458]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:116)[107:org.eclipse.smarthome.model.core:0.8.0.201604051458]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.checkFile(FolderObserver.java:240)[107:org.eclipse.smarthome.model.core:0.8.0.201604051458]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.access$1(FolderObserver.java:235)[107:org.eclipse.smarthome.model.core:0.8.0.201604051458]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver$WatchQueueReader.processWatchEvent(FolderObserver.java:117)[107:org.eclipse.smarthome.model.core:0.8.0.201604051458]
at org.eclipse.smarthome.core.service.AbstractWatchQueueReader.run(AbstractWatchQueueReader.java:95)[88:org.eclipse.smarthome.core:0.8.0.201604051458]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_66]
22:34:40.612 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'mysensors:bridge-ser:gateway' has been updated.
22:34:40.620 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'mysensors.things'
22:34:40.815 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 0;0;3;0;2;
22:34:45.619 [ERROR] [s.internal.MySensorsBridgeConnection] - Cannot start reading/writing thread, probably sync message (I_VERSION) not received
22:34:45.619 [DEBUG] [col.serial.MySensorsSerialConnection] - Shutting down serial connection!
22:34:45.619 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Stopping Writer thread
22:34:45.621 [WARN ] [g.mysensors.protocol.MySensorsWriter] - Writer thread interrupted
22:34:45.621 [DEBUG] [g.mysensors.protocol.MySensorsReader] - Stopping Reader threadHi all,
After battling with some radio issues with my sensors (in the RFM69 library) I am again ready to get things working using OH2. I downloaded the latest copy of the binding, but sadly things are not working for me. I believe the problem is still related to collecting to the serial port. I have lots of zwave stuff going on in my log, but i have included it anyhow in case someone feels the urge to take a look :-).
0_1461437647445_temporary log
I'm afraid we might be fighting two different problems. But anyway, we've made some breakthrough on my problems :-). It appears to be related to the radio having trouble to catch the entire first packet after waking from standby. It seems to work better when waking from sleep. If you check my last post in this thread https://lowpowerlab.com/forum/index.php/topic,1821.msg13160.html#msg13160 you can see what I have done to change the idle behaviour for the radio. The node is now able to process acknowledgements to all the messages it sends. There are still some issues, but for me this is a great improvement.
Following from this I have patched my copy of the MySensors development branch with the latest RFM69 library with my small patch. I also did a small change to the RFMTransport to change when/how it sends acknowledgements to messages in transportReceive. I have run a gateway and energy meter sensor since last night (around 14 hours) and the communication has worked flawlessly for that period. This is the first in a very long time
Weird, I'm curious to hear what you find.
I have a thread on going at the lowpower forum trying to figure out my own problems: https://lowpowerlab.com/forum/index.php/topic,1821.0.html
For my part the problem is clearly unrelated to MySensors, but I find it difficult to believe that it is a hardware problem when it affects so many devices (unless it is an age thing or I managed to break them all at once).
I'm using a standard Moteino USB with nothing else attached (apart from the USB cable and antenna).
@hek It has to be something wrong with my devices, although that doesn't make sense when I've tested so many. Anyway, I posted on the moteino forum, so let's see what they have to say about it.
Some further information. I have tested with the library directly from the moteino site. I have the Gateway running on one node and the "node" running on another. The first time I ran the sketches things looked pretty well, apart from a few packets being lost. However, on subsequent runs it appears that the Gateway is receiving the messages (rssi = -29), but it is not able to send the ack to the node (or the node is not able to hear it). The node responds with "nothing..." After each transmission attempts, while the Gateway sends at least two ACKs per message it receives from the node. However, the Gateway does not receive any response when it tries to ping the node.
I have changed which device is the node and the Gateway, and even included a third device as both, and the behaviour is always the same. The Gateway receives packets, but not the node.
I'm aware that the above explanation makes no sense if you're not familiar with the Gateway and node test sketches for moteino
For reference, the full sensor start-up log looks like this:
Starting sensor (RRNNA-, 2.0.0-beta)
Radio init successful.
send: 3-3-0-0 s=255,c=3,t=15,pt=0,l=2,sg=0,st=fail:
send: 3-3-0-0 s=255,c=0,t=17,pt=0,l=10,sg=0,st=fail:2.0.0-beta
send: 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=fail:0
send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=12,sg=0,st=fail:Energy Meter
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=fail:1.0
send: 3-3-0-0 s=1,c=0,t=13,pt=0,l=0,sg=0,st=fail:
find parent
send: 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
Init complete, id=3, parent=0, distance=255
And the Gateway looks like this:
0;255;3;0;9;Starting gateway (RRNGA-, 2.0.0-beta)
0;255;3;0;9;Radio init successful.
0;255;3;0;14;Gateway startup complete.
0;255;3;0;9;Init complete, id=0, parent=0, distance=0
Some messages do get through, sometimes, though:
Sensor:
find parent
send: 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
read: 0-0-3 s=255,c=3,t=15,pt=0,l=2,sg=0:
Gateway:
0;255;3;0;9;read: 3-3-0 s=255,c=3,t=15,pt=0,l=2,sg=0:
0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=15,pt=0,l=2,sg=0,st=ok:Hi,
I've had some troubles with my sensors lately, but I have not really had time to dig into it. I therefore thought I would start from scratch with the latest development branch to see if things got better.
I'm trying to get two moteinos with the RFM69HW radio at 868 MHz to communicate to each other. I have loaded one with the Gateway example with a falling two defines:
#define MY_RADIO_RFM69
#define MY_IS_RFM69HW
The other I have loaded with the energy pulse meter since that is the sensor I am trying to get to work. The first time I did this everything seem to initialising fine, and the Gateway received the messages from the sensor initialising. However, there were a few st:fail messages from the sensor. I uploaded the sketches multiple times with minor changes to the sensor and at some point nothing got through. Every message from the sensor failed. I did not change anything in the initialisation and, only in the logic to count the energy pulses. I even tried with different boards, switching the Gateway and sensor, but nothing helped. Am I missing anything in the set up for the radio?
I should also mention that I have had issues with version 1.5 of the library as well on the same hardware. Therefore, I am not sure if it is a hardware problem or my use of the library that is at fault. Still, as I said, I have tried with multiple boards, both old that was working before and one that has never been used before.
Any suggestions are appreciated.
Thanks.
I managed to get things working pretty well under Linux, but I have now switched to a Windows-based installation to see how that is.
Currently I have all three bindings working at the same time using three different serial ports. This is finally allowed me to pay attention to what the mysensors binding is doing.
The seems to be some kind of delay through the system for messages coming from the device. This is quite evident from the log included below. Device number three is a power sensor which transmits about once a minute. For some reason things are bunched together. I guess some of these could be Retransmissions, though. The sensor is located 4 m away from the gateway. Number 10 is a temperature sensor in the basement.
For some reason I have had severe problems getting the sensor to talk to the Gateway today. It shouldn't be related to the binding, I know, but I'm loosing my mind trying to keep track of all the different factors here.
2016-04-10 16:56:19.535 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 10;1;1;0;0;6.3
2016-04-10 16:56:20.512 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 10;1;1;0;0;6.3
2016-04-10 16:56:21.747 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 10;1;1;0;0;6.3
2016-04-10 16:56:21.805 [INFO ] [marthome.event.ItemStateChangedEvent] - FirstFloorHallMotionSensor changed from ON to OFF
2016-04-10 16:56:21.805 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_command changed from ON to OFF
2016-04-10 16:56:21.806 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_dimmingLevel changed from 100 to 0
2016-04-10 16:56:21.807 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_contact changed from OPEN to CLOSED
2016-04-10 16:56:24.922 [INFO ] [marthome.event.ItemStateChangedEvent] - FirstFloorHallMotionSensor changed from OFF to ON
2016-04-10 16:56:24.923 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_command changed from OFF to ON
2016-04-10 16:56:24.924 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_dimmingLevel changed from 0 to 100
2016-04-10 16:56:24.926 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_contact changed from CLOSED to OPEN
2016-04-10 16:56:55.048 [INFO ] [marthome.event.ItemStateChangedEvent] - CurrentDate changed from 2016-04-10T16:55:55.046+0200 to 2016-04-10T16:56:55.045+0200
2016-04-10 16:56:55.049 [INFO ] [ome.event.GroupItemStateChangedEvent] - ntp_ntp_local changed from 2016-04-10T16:55:55.046+0200 to 2016-04-10T16:56:55.045+0200 through ntp_ntp_local_dateTime
2016-04-10 16:56:55.049 [INFO ] [marthome.event.ItemStateChangedEvent] - ntp_ntp_local_dateTime changed from 2016-04-10T16:55:55.046+0200 to 2016-04-10T16:56:55.045+0200
2016-04-10 16:57:08.332 [INFO ] [marthome.event.ItemStateChangedEvent] - FirstFloorHallMotionSensor changed from ON to OFF
2016-04-10 16:57:08.333 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_command changed from ON to OFF
2016-04-10 16:57:08.334 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_dimmingLevel changed from 100 to 0
2016-04-10 16:57:08.334 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_contact changed from OPEN to CLOSED
2016-04-10 16:57:13.444 [INFO ] [marthome.event.ItemStateChangedEvent] - MainHallMotionSensor changed from OFF to ON
2016-04-10 16:57:13.445 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15663466_10_command changed from OFF to ON
2016-04-10 16:57:13.450 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15663466_10_dimmingLevel changed from 0 to 100
2016-04-10 16:57:13.451 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15663466_10_contact changed from CLOSED to OPEN
2016-04-10 16:57:23.053 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 10;1;1;0;0;6.3
2016-04-10 16:57:24.511 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;17;9223
2016-04-10 16:57:24.513 [INFO ] [marthome.event.ItemStateChangedEvent] - CurrentTotalPower changed from 6559 to 9223
2016-04-10 16:57:24.519 [INFO ] [marthome.event.ItemStateChangedEvent] - AverageTotalPower changed from 6559 to 9223
2016-04-10 16:57:24.798 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;17;9223
2016-04-10 16:57:25.616 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;24;4597
2016-04-10 16:57:27.075 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;24;4597
2016-04-10 16:57:29.766 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;24;4597
2016-04-10 16:57:31.128 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;18;4.6050Returns out that I am still seeing the problem sometimes. If I change the configuration so that the bindings are reloaded (especially the zwav binding) it fails to reconnect to the serial port. I found someone who had posted an updated serial binding which supposedly solved some related problem (I think), but I'm not sure. It does not appear to have had any effect on the problem.
The modified version is available from one of the last posts here: https://github.com/openhab/openhab2-addons/issues/671
Success, I think.
I started a brand-new installation of the latest OH2 snapshot, and sequentially added the rfxcom, z-wave, and mysensors bindings. After fiddling a bit with getting serial ports recognised by OH2 and getting the permissions correct, it seems to work. I still get some weird error messages, but apparently the library is able to work through its issues :-). An example of what I mean is included.
08:30:03.894 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'mysensors:bridge-ser:334037be' has been added.
08:30:03.910 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:334037be' changed from UNINITIALIZED to INITIALIZING
RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..rfxtrxUSB: File exists. It is mine
@�2� testRead() Lock file failed
RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyACM0: File exists. It is mine
@�2� testRead() Lock file failed
08:30:04.043 [INFO ] [smarthome.event.ItemAddedEvent ] - Item 'mysensors_bridge_ser_334037be' has been added.
08:30:04.219 [INFO ] [rthome.event.ItemThingLinkAddedEvent] - Link 'mysensors_bridge_ser_334037be-mysensors:bridge-ser:334037be' has been added.
08:30:07.060 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:334037be' changed from INITIALIZING to ONLINEIt appears that I get these errors even if I remove all the offending bindings. I think I need to start with a completely clean installation and see how it goes. I will let you know.
@TimO I tried this before, and removing the MySensors binding made the rfxcom binding work. However, this was not the case this time. I will try a bit later to also remove the zwave binding.
20:56:34.098 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:43b9314d' changed from UNINITIALIZED to INITIALIZING
20:56:34.115 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
20:56:34.115 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:43b9314d' changed from INITIALIZING to ONLINE
RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyACM0
20:56:34.361 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
20:56:34.384 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
20:56:34.385 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
20:56:34.419 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:43b9314d' changed from ONLINE to INITIALIZING
20:56:34.444 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'sonos:zoneplayer:RINCON_5CAAFD2BB4D801400' has been updated.
20:56:34.578 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'sonos:zoneplayer:RINCON_5CAAFD21C16201400' has been updated.
20:56:34.756 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'sonos:zoneplayer:RINCON_5CAAFD2BB4FE01400' has been updated.
20:56:34.852 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
20:56:34.866 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'hue:bridge:0017881c7280' has been updated.
20:56:34.869 [INFO ] [assic.internal.servlet.WebAppServlet] - Started Classic UI at /classicui/app
20:56:34.998 [INFO ] [.openhab.core.internal.CoreActivator] - openHAB runtime has been started (v2.0.0, build 201602200203).
20:56:35.015 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'demo.sitemap'
20:56:35.444 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mysensors.things'
20:56:35.491 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'mysensors:bridge-ser:gateway' has been added.
20:56:35.500 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from UNINITIALIZED to INITIALIZING
RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyACM0: File exists. It is mine
�a�� testRead() Lock file failed
RXTX Warning: Removing stale lock file. /var/lock/LCK..mysensorsUSB
20:56:37.420 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 37: Not initialized yet, ignoring message.
20:56:37.426 [ERROR] [WaveSerialHandler$ZWaveReceiveThread] - Protocol error (CAN), resending
20:56:37.427 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 37: Not initialized yet, ignoring message.
20:56:37.429 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 37: Not initialized yet, ignoring message.
20:56:38.773 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from INITIALIZING to ONLINE
20:56:38.774 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'rfxcom.things'
20:56:38.780 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'rfxcom:bridge:rfxtrx' has been added.
20:56:38.790 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'rfxcom:bridge:rfxtrx' changed from UNINITIALIZED to INITIALIZING
20:56:38.792 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'rfxcom:bridge:rfxtrx' changed from INITIALIZING to OFFLINE
RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..mysensorsUSB: File exists. It is mine
�`�� testRead() Lock file failed
20:56:38.805 [ERROR] [g.rfxcom.handler.RFXComBridgeHandler] - Connection to RFXCOM transceiver failed: nullThe weird thing is that it seems to work with an older version of OH2 (and an old version of your binding), but not with the more recent beta releases.
@TimO Thanks for the update. Unfortunately it did not seem to change anything for me, rfxcom still fails trying to use the wrong lock file. If it is helpful I can send you the log. Appreciate your input and effort.
It is both zwave and rfxcom. I played about it in the oh2 community some time ago, let me see if I can find a link.
Are any of you having trouble with this binding together with other bindings that use serial ports? It looks as if the different bindings try to use the same serial port lock, so I get a conflict where things fail til initialize. Think it had something to do with the serial port library...
Thanks, that was quick. However, something is not right:
2015-11-23 17:47:17 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:multimeter, mysensors:power, mysensors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, mysensors:light-level]' on 'MySensorsDiscoveryService'...
2015-11-23 17:47:17 [ERROR] [i.DiscoveryServiceRegistryImpl:339 ] - Cannot trigger scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:multimeter, mysensors:power, mysensors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, mysensors:light-level]' on 'MySensorsDiscoveryService'!java.lang.NullPointerException: null
at org.openhab.binding.mysensors.service.DiscoveryThread.stop(DiscoveryThread.java:23)
at org.openhab.binding.mysensors.discovery.MySensorsDiscoveryService.stopScan(MySensorsDiscoveryService.java:63)
at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:173)
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:336)
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScans(DiscoveryServiceRegistryImpl.java:321)
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:172)
at org.eclipse.smarthome.io.rest.core.discovery.DiscoveryResource.scan(DiscoveryResource.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)Also, from where can we download the latest versions of your binding?
@TimO Would it be too much trouble for you to implement support for S_MULTIMETER? It seems that this is required for me to get the voltage reading from my battery driven sensors. Alternatively, is there anything you can do with the battery percentage that is sent using sendBatteryPercent? I don't know if OH2 has any notion of the sensors battery level?
I notice you have support for the type S_VOLTAGE, but I cannot find that this is present in the master branch of MySensors?
For what it's worth, I'm using openhab 2 with a version from yesterday together with the latest my sensor binding I found here. Serial gateway and serial aeon stick zwave controller (latest binding from the build server). Absolutely no issues for me.
Sorry, I used the native mysensors support, not mqtt.
@TimO Great work, I will try to test it tonight.
It appears from the discussion that official support for getting the values in the binding seems unlikely.
I guess you could argue that as long as the thing and openhab are not rebooted at the same time, the count should be consistent from the thing. But perhaps he is right, maybe it is better to just keep the total count inside openhab and create a rule to calculate the total power consumed based on our knowledge of number of pulses per kwh, for instance?
On the other hand, was about something like a lock which needs to know its last state if it was not written to EEPROM, is this also beyond the scope of what the binding should be able to do?
There it is, the Child ID is included in the request message :-). Sorry for the confusion caused by my lack of observation skills.
Yes, but how does it know what to send as a response to a generic request. Everything? A single specific variable? In that case, which variable?
Sorry for bringing this thread off track. Maybe I should take this off-line with @hek or try to read some documentation to understand this better, at least until we see whether @TimO wants to do anything like this at all.
Fair point, and the ultimate solution should definitely support this.
Still, I think my suggestion could be useful and much easier to implement on the binding side (and sensor side) since it requires no user configuration in openhab (apart from possibly a checkbox to enable/disable the functionality). The only user interaction required is to actually consume the messages in the node and do something useful with them, if desired. So maybe it is a useful start?
In the pulse sensor example, what should be providing the data when it is requested by the node?
@hek Exactly, I saw that and had to remove it before implementing your version of the pulse counter :-).
So my point is still valid, I guess, the binding has to listen for variable requests and respond to them. The question is then how does it know which variable is requested? That is why I thought it would be easier if you just sent all the date eight had using the same message types as they reported from the sensor.
@TimO Your binding and your plans moving forward. Some sensors rely on some kind of persistence to know the last state before a reboot. Examples include the power sensor that wants to know the total power usage overall (mine is currently lost after every reboot), a lock (you want to ensure that the looked does not change state after a reboot), and probably many other devices as well. Some of these can safely be stored to EEPROM as they do not change very often, but others such as the power usage changes at every measurements and it does not make sense to write to ROM.
One way this has been solved in sensor examples is to have the sensor request the latest value from the gateway, which in turn will pass the request along to any monitoring application. Do you have any plans/is it possible for the binding to support something like this?
In the examples I have seen the sensor and Gateway have used a generic VAR1 variable to communicate this data, but perhaps it is possible for the binding to implement a more generic solution? What if whenever you receive the hello from a sensors node indicating that it has booted, if there is a stored data for that node and child ID, transmit this data to the node using the same type of message as the node sends to the gateway. This has to have a limited number of retries in case the node does not expect such messages. It is then up to the node developer to decide whether he wants to pick up these last state messages from the gateway or not.
Does this make sense and is it useful? Or is that perhaps already some kind of support for this communication in the MySensors library (@hek)?
I'm just thinking out loud here...
@Jan-Gatzke I think autodiscovery refers to automatically adding sensors to the system as they present themselves when they are booted. Assigning IDs is a completely different thing, I believe.
I simply removed all my existing things, restarted the server, and then rebooted the sensors when in "discovery" mode. This made everything appear magically
@TimO Thank you very much for your excellent work :-).
I have done some more testing, and I can report that discovery of sensors seems to work flawlessly (at least for the supported types ;-)). I like the change you made to the naming, it makes the default names much more easy to distinguish. As for renaming the elements, I will just have to play a bit around with that on my own, I guess.
The new types seem to work well, but there is a problem when updating the light switches. It apparently does not like a DecimalType when updating the item. The light switch command looks like this: 6;4;1;0;2;1
Also, the the updates appear twice in the log which is a bit weird.
I set up two of my sensors, including a sensor type you have not yet implemented, the distance sensor. Two of the sensor reports looks like this:
6;5;1;0;13;1.0
6;5;1;0;13;0.7
Apart from the small issues I'm very impressed with the implementation
I apologise for sending you the wrong log, I was not aware of its location in 2.0. Hopefully I should now have attached the right one.
openhab.log
This is what the sensors currently look like in my simple setup:
Edit: I should mention that switching the sensor on and off from the widgets on the page seems to work correctly, even though it does not report if the sensor is switched using its local interface (hardware interface, a button soldered to the sensor).
@Jan-Gatzke I did not make any changes either to my Gateway or to the openhab configuration. I'm running at the default serial Gateway speed which I guess is 115200?
My five mins of experience:
Setting up the serial Gateway thing work without problems, and I was also able to add a temperature sensor.
BUG: Changing the name of the new thing (temperature sensor) was not successful. It stubbornly remained "Temperature sensor".
Also, it does not seem to get any values even though they are reported in the log, but this might just be some kind of sluggishness?
The same is the case for the humidity values. Example reports listed in the log: 6;2;1;0;1;48.0 (humidity)
Edit: Humidity got updated, but I still get no update for the temperature.
Updated log: server.log
@TimO It would be great if you could implement support for the power type. My sensor reports the following two values:
3;1;1;0;17;2810, the current power consumption (Watt)
3;1;1;0;18;106.2550, the overall power usage since sensor boot (KWH)
It would also be good to be able to get the Gateway log messages such as this: 0;0;3;0;9;Gateway is alive.
This is basically the only thing missing for me apart from the temperature and humidity sensors for the moment. I could give you some examples for barometric pressure and the resulting forecast message based on this if you're interested. I also think I have a sensor lying around that reports distance (actually it's time remaining, but it's using the distance type).
Edit: The few sensors I have running at the moment should have reports available in the log file I included in the next post if you want something to look at
Edit: Barometer forecast message: 6;3;1;0;5;stable
I'm also using the serial Gateway via a mqtt perl script to send recorded values to the broker, and then a is the mqtt binding in openhab to communicate with the sensor network.
Yes, we have a three phase power, into the building, as was going out to both the bon and the secondary house. I've been looking into getting one of these clamp power meters, but I'm not sure if these can deal with a three-phase power. I would very much like to be able to measure the amount of power that is consumed by the secondary house so that I can get an exact amount he should pay for the electricity bill :-).
Do you have any experience with using clamp power meters on three-phase power?
Thanks for the suggestions, and for the proof that can actually work long-term :-).
I have now replaced the 220 V adapter with another one, so let's see how it goes now.
@Francois: I assume youre figures are from domoticz or something similar? How do you like it? I have used openhab for quite some time before I tried to switch to domoticz for a few months. I found that adding new sensors and displaying data was much easier in domoitcz, but the rule and persistence system of openhab is much better, as much so as to outweigh the benefits of domoticz. I switched back to Openhab a few weeks ago.
BTW, you don't want to see my power Usage numbers, they average around 5000W with a peak at nearly 15 kilowatts, Depending on what is running. This covers a full farm with two houses, a big barn, and some other stuff, but still...
The radio is integrated into the Arduino board, so it is difficult for me to do anything with the radio VCC line. Anyway, the gateway is powered directly by the computer, home of the power sensor is powered by a Samsung charger which should be relatively good quality?
I'm still having some problems with the sensors being a bit unreliable. For instance, I have a Power sensor that detects LED blinks off my power meter and switches its own LED at every blink so that I can actually see if anything is happening. This works fine for several days, and power usage reports are sent to the gateway at regular intervals (two minutes), but then suddenly the power reports stop. The LED keeps blinking, indicating that the sketch is actually doing what it is supposed to, but for some reason the radio stops doing anything.
I have also had this happen on the gateway, the radio stopped responding after some time even though the sketch seems to be running. This is both on the moteino and anarduino with the RF 69 radios.
I have no idea what is causing this, but my best guess is that some kind of buffer is overrun, or maybe a counter?
Not really sure how to debug a problem like this, but I think the first attempt will be to try to reinitialise the radio after a specific amount of time to see if this clears the problem. The time before the issues occur can vary from 10 hours to 5 days, though, so it is a bit difficult to test...
Simple. We share our locations through Google, so we always can see where each other are 
In the belief that not everything has to be overcomplicated (ref my other post about hacking a water timer), let me share my most recent project with you.
I have a robotic lawnmower that covers a pretty complicated lawn of about 3500 m². Being only a simple robot it tends to get stuck here and there, and sometimes it has to take the long way home with too little fuel. In these cases it would be good to get a notification so that I could go out and look for him when he gets stuck, but be pretty confident that he is working correctly otherwise.
Enter my sensor.
It is nothing fancy, simply a reed switch connected to the interrupt pin (number three) on my moteino and a battery pack. The magnets for the switch is mounted on the lawnmower. Domoticz now knows when he is home and when he is out. Knowing how long he usually works for I can now easily set up an alarm which fires whenever he has been away too long (which means that he is probably stuck, or God forbid, stolen).
Again, it is nothing fancy, but it works :-). I hope you guys forgive me for my casings and wiring. I am much more a software guy than a hardware guy, and it shows
I just tested this, and both the pinChange interrupt and the timer interrupts work great.
As far as I can tell my sketch works with timer interrupts as well as the pin interrupts.
I have not tested this thoroughly, though.
I took a quick look at the water pulse sketch. I believe that the only change required is to replace attachInterrupt with enableInterrupt and choose a pin other than 2 or 3 which are connected to the external interrupts.
Adding multiple sensors simply requires the sensor to be connected to different pins and enabled using enableInterrupt. Make sure not to use anything else that uses interrupts inside the handler such as serial.print or anything related to the radio. It probably can't use anything related to the time, either, since sleeping breaks timing.
I have included my sketch here. It uses the RF69 radio on a moteino platform. Since I'm lazy I have added the weather shield also from lowpowerlabs. In addition to the sensors on this I use a soil moisture sensor, and I have added support for three interrupt driven reed switches (for one door and two Windows).
I downloaded the latest version of the EnableInterrupts library from the link in my first post and made the following changes to EnableInterrupts.h. I cannot guarantee that these changes will work for everyone, but I suspect it at least should work on the 328p versions of the process that used on the moteino and other similar arduinos
Comment out lines 956 to 999:
/*
ISR(INT0_vect) {
#ifndef NEEDFORSPEED
(*functionPointerArrayEXTERNAL[0])();
#else
#if defined ARDUINO_MEGA
#ifdef INTERRUPT_FLAG_PIN21
INTERRUPT_FLAG_PIN21++;
#endif
#endif
#if defined ARDUINO_LEONARDO
#ifdef INTERRUPT_FLAG_PIN3
INTERRUPT_FLAG_PIN3++;
#endif
#endif
#if defined ARDUINO_328
#ifdef INTERRUPT_FLAG_PIN2
INTERRUPT_FLAG_PIN2++;
#endif
#endif
#endif // NEEDFORSPEED
}
ISR(INT1_vect) {
#ifndef NEEDFORSPEED
(*functionPointerArrayEXTERNAL[1])();
#else
#if defined ARDUINO_MEGA
#ifdef INTERRUPT_FLAG_PIN20
INTERRUPT_FLAG_PIN20++;
#endif
#endif
#if defined ARDUINO_LEONARDO
#ifdef INTERRUPT_FLAG_PIN2
INTERRUPT_FLAG_PIN2++;
#endif
#endif
#if defined ARDUINO_328
#ifdef INTERRUPT_FLAG_PIN3
INTERRUPT_FLAG_PIN3++;
#endif
#endif
#endif // NEEDFORSPEED
}
*/
Comment out the last part of the line 480:
arduinoPin=interruptDesignator;// & ~PINCHANGEINTERRUPT;
Here is the sketch. I have commented out the code related to the environmental sensors since I have not yet attached these to the board.
#include <EnableInterrupt.h>
#include <MySigningNone.h>
#include <MyTransportRFM69.h>
#include <MyTransportNRF24.h>
#include <MyHwATMega328.h>
#include <MySigningAtsha204Soft.h>
#include <MySigningAtsha204.h>
#include <MySensor.h>
#include <SPI.h>
#include <DHT.h>
#include <Bounce2.h>
#include <SFE_BMP180.h> //get it here: https://github.com/LowPowerLab/SFE_BMP180
#include <SI7021.h> //get it here: https://github.com/LowPowerLab/SI7021
#include <Wire.h>
#define REPORT_INTERVAL 9000
#define ALTITUDE 220
#define BUTTON 3 //cannot change because of interrupt
#define MOISTURE A4
#define DOOR 5
#define WINDOW_ONE 6
#define WINDOW_TWO 7
#define CHILD_TEMPERATURE 1
#define CHILD_HUMIDITY 2
#define CHILD_PRESSURE 3
#define CHILD_MOISTURE 4
#define CHILD_DOOR 5
#define CHILD_WINDOW_ONE 6
#define CHILD_WINDOW_TWO 7
#define CHILD_POWER 9
SI7021 sensor;
SFE_BMP180 pressure;
int BATTERY_SENSE_PIN = A7; // select the input pin for the battery sense point
MyTransportRFM69 transport;
// Hardware profile
MyHwATMega328 hw;
MySensor gw(transport, hw /*, signer*/);
// Change to V_LIGHT if you use S_LIGHT in presentation below
MyMessage temperatureMessage(CHILD_TEMPERATURE, V_TEMP);
MyMessage humidityMessage(CHILD_HUMIDITY, V_HUM);
MyMessage pressureMessage(CHILD_PRESSURE, V_PRESSURE);
MyMessage moistureMessage(CHILD_MOISTURE, V_HUM);
MyMessage doorMessage(CHILD_DOOR, V_TRIPPED);
MyMessage windowOneMessage(CHILD_WINDOW_ONE, V_TRIPPED);
MyMessage windowTwoMessage(CHILD_WINDOW_TWO, V_TRIPPED);
MyMessage powerMessage(CHILD_POWER, V_VOLTAGE);
unsigned long lastReport = 0, time, buttonStart = 0, buttonFinish = 0, lastCheck = 0, lastReduce = 0;
void setup()
{
pinMode(BATTERY_SENSE_PIN, INPUT);
pinMode(DOOR, INPUT_PULLUP);
pinMode(WINDOW_ONE, INPUT_PULLUP);
pinMode(WINDOW_TWO, INPUT_PULLUP);
sensor.begin();
pressure.begin();
gw.begin(NULL, 7, false);
gw.sendSketchInfo("Water control", "1.0");
delay(250);
gw.present(CHILD_TEMPERATURE, S_TEMP);
delay(250);
gw.present(CHILD_HUMIDITY, S_HUM);
delay(250);
gw.present(CHILD_MOISTURE, S_HUM);
delay(250);
gw.present(CHILD_PRESSURE, S_BARO);
delay(250);
gw.present(CHILD_DOOR, S_DOOR);
delay(250);
gw.present(CHILD_WINDOW_ONE, S_DOOR);
delay(250);
gw.present(CHILD_WINDOW_TWO, S_DOOR);
delay(250);
gw.present(CHILD_POWER, S_POWER);
enableInterrupt(DOOR, notifyDoor, CHANGE);
enableInterrupt(WINDOW_ONE, notifyWindowOne, CHANGE);
enableInterrupt(WINDOW_TWO, notifyWindowTwo, CHANGE);
}
volatile int doorInterrupt = 0, windowOneInterrupt = 0, windowToInterrupt = 0;
void notifyDoor() {
// gw.send(doorMessage.set(digitalRead(DOOR)));
doorInterrupt++;
}
void notifyWindowOne() {
// gw.send(windowOneMessage.set(digitalRead(WINDOW_ONE)));
windowOneInterrupt++;
}
void notifyWindowTwo() {
// gw.send(windowTwoMessage.set(digitalRead(WINDOW_TWO)));
windowToInterrupt++;
}
// Check if digital input has changed and send in new value
void loop()
{
// Get the update value
gw.process();
if (doorInterrupt > 0) {
gw.send(doorMessage.set(digitalRead(DOOR)));
doorInterrupt = 0;
}
if (windowOneInterrupt > 0) {
gw.send(windowOneMessage.set(digitalRead(WINDOW_ONE)));
windowOneInterrupt = 0;
}
if (windowToInterrupt > 0) {
gw.send(windowTwoMessage.set(digitalRead(WINDOW_TWO)));
windowToInterrupt = 0;
}
//*************** READING BATTERY VOLTAGE *********************
//turn MOSFET ON and read voltage, should give a valid reading
pinMode(A3, OUTPUT);
digitalWrite(A3, LOW);
Serial.print(" BATT: ");
int sensorValue = analogRead(A7);
Serial.println(sensorValue);
float batteryV = sensorValue / 10 * 0.00520430107;
int batteryPcnt = sensorValue / 100;
gw.send(powerMessage.set(batteryV, 1));
gw.sendBatteryLevel(batteryPcnt);
pinMode(A3, INPUT); //put A3 in HI-Z mode (to allow mosfet gate pullup to turn it OFF)
//*************** READING BATTERY VOLTAGE *********************
float moistureReading = analogRead(MOISTURE);
Serial.println(moistureReading);
gw.send(moistureMessage.set(100 * (1024 - moistureReading) / 1024.0, 1));
Serial.println("************ BMP180 *********************************");
Serial.print("provided altitude: ");
Serial.print(ALTITUDE, 0);
Serial.print(" meters, ");
Serial.print(ALTITUDE * 3.28084, 0);
Serial.println(" feet");
/*
float temperature = sensor.getCelsiusHundredths() / 100;
Serial.println("************ Si7021 *********************************");
Serial.print("C: "); Serial.print(temperature);
int humidity = sensor.getHumidityPercent();
Serial.print(" H: "); Serial.print(humidity); Serial.print("% ");
gw.send(temperatureMessage.set(temperature, 1));
gw.send(humidityMessage.set(humidity, 1));
char status;
double T, P, p0, a;
status = pressure.startTemperature();
if (status != 0)
{
// Wait for the measurement to complete:
delay(status);
// Retrieve the completed temperature measurement:
// Note that the measurement is stored in the variable T.
// Function returns 1 if successful, 0 if failure.
status = pressure.getTemperature(T);
if (status != 0) {
Serial.print("C: ");
Serial.print(T, 2);
Serial.print(" F:");
Serial.print((9.0 / 5.0)*T + 32.0, 2);
Serial.println("");
status = pressure.startPressure(3);
if (status != 0)
{
delay(status);
status = pressure.getPressure(P, T);
if (status != 0)
{
// Print out the measurement:
Serial.print("abs pressure: ");
Serial.print(P, 2);
Serial.print(" mb, ");
Serial.print(P * 0.0295333727, 2);
Serial.println(" inHg");
// The pressure sensor returns abolute pressure, which varies with altitude.
// To remove the effects of altitude, use the sealevel function and your current altitude.
// This number is commonly used in weather reports.
// Parameters: P = absolute pressure in mb, ALTITUDE = current altitude in m.
// Result: p0 = sea-level compensated pressure in mb
p0 = pressure.sealevel(P, ALTITUDE); // we're at 1655 meters (Boulder, CO)
Serial.print("relative (sea-level) pressure: ");
Serial.print(p0, 2);
Serial.print(" mb, ");
Serial.print(p0 * 0.0295333727, 2);
Serial.println(" inHg");
gw.send(pressureMessage.set(p0, 1));
}
}
}
}
*/
gw.sleep(REPORT_INTERVAL);
}```Hi guys,
I previously posted a question regarding how to use multiple interrupts on my Arduino together with my RF 69 radio. The suggestion was to use pinChangeInt, but I couldn't exactly get it to work.i decided to pick this up again today, and I found this new library which appears to supersede it, called EnableInterrupt.
https://github.com/GreyGnome/EnableInterrupt
At first it did not work since it apparently had some kind of conflict with the radio library which relies on interrupt 0, and possibly also something in the mysensors framework related to sleeping, I guess? Anyway, since I didn't needed to handle the external interrupts, just the pinChangeInt, I was able to modify the header file to remove the clashing definitions.
I finally have a working sensor that can cover multiple buttons and reed switches through interrupts. This means it can sleep most of the time, but still wake and act immediately if something changes
@Moshe-Livne I agree that a floating valve would be a better solution if you had a fixed installation. This would allow you to keep the water on at all times and have the water barrel top itself off continuously. We have such a system, but it is a pain to run the pipes to everywhere the horses need the water, especially in winter when it's freezing. This means we have one of these, but the rest are filled using a regular hose.
The implemented solution works well for having a hose lying around and stretching it to wherever we need to fill the buckets without wasting water or ruining the area by getting too wet. This has happened several times already, and not only was it a pain to clean up, but it also emptied our well so we had to go down and manually restarted everything by filling the system with water.
In short, it is a failsafe system to guard against our own forgetfulness with a great deal of flexibility
@betonishard That is actually a good idea, although I would have to do that with a separate sensor since the barrels are in a different room. I envision the following:
I have three wires into the barrel. One is at the bottom (ground), and the two others are affixed to the side (digital inputs). One at a low position and one at a high position. I can then detect when the water is low and when it is high.
Makes sense? Or is there a better way of doing this?
I'm actually slightly worried about that. Since I needed to count time and to receive packets I can't have it sleeping all the time. That means it has to be run off of mains power instead of batteries (the water thing itself runs on batteries)., The 220 V extension cord is someways away from the thing, so the only power that reaches near water is 5 V. I don't expect this to be a serious problem, but you never know.
On the other hand, we use heating cables inside the water pipes to keep them unfrozen during winter which is the full 220 V (and this is done professionally) so my 5 V shouldn't be a problem
We have a bunch of horses and we need to fill the water troughs several times a day. Trouble is, we sometimes forget to turn off the water which results in 100 m² of wet wood shavings that have to be shovelled out and replaced. In an effort to fix this I bought a water timer from our local cheap things shop. Unfortunately this was designed to water plants with the only possible settings on, off, and turn on for X minutes every Y hours. It was cheap, though, so I bought it thinking that I could hack it. It turned out that I was not able to control the motor inside the unit directly, but I could manipulate the input signals for the on-board microprocessor. By using a relay and shorting two different circuits I could turn the water on and off digitally
Add a button, a LED, some environmental sensors because why not?, And of course the radio module and we have something fun that works.
Each press of the button adds one minutes to the "on" time. As long as this time is greater than zero keep the water running, and shut it off when the timer expires. Every 15 seconds the LED blinks to indicate the number of remaining minutes of on time. Long press the button to reset the time and shut off the water. The state of the switch and the time remaining is relayed to domoticz as a light switch and a distance sensor (the closest match I could find). The light switch can of course also be triggered from domoticz, giving us multiple options for turning on and off the water. Turning on the water from the computer simply sets the timer to 10 minutes to ensure that it will be automatically shut off at some point.
It doesn't look great, but it's solves a real problem
There should be a recent topic on this somewhere in the forum. I can look it up when I'm at the computer later.
I guess it mostly depends on what you have available and where you want to place the Gateway. With the serial option you have to have the Gateway quite close to your computer, while with the ethernet option you can have them further apart.
On the other hand, the ethernet option can be more expensive than the serial option since you need an ethernet adapter for the gateway.
For my part I'm quite happy using the serial Gateway together with OpenHAB (earlier) and now testing it with Domoticz without any problems.
Eventually I got it to compile by deleting my current subversion version and doing a new checkout of revision 2361. I think the reason why this didn't work the first time was that I wasn't able to clean the compile environments enough after checking out the earlier version. This revision is reported to work by many people in the forum, and for me as well.
I have spent the past few days playing with it, and I have it controlling my zwave network, my nexa and Oregon scientific devices through rfxcom, and finally my mysensors devices, all without any additional plug-ins
I have also managed to get mqtt working space by using the approach outlined in the wiki, but I have no idea how to access the apparently built-in mqtt support. My plan for today is to post notification messages to my mqtt broker so that they can be picked up by mqttwarn.
I like that they have a graphical rule building interface, this makes it easy for new users, but I found that I quickly reverted to the lua scripting functionality. Both because it is much more powerful, and it's actually faster to work with this than a graphical interface
@reddy11 Sure, you can find it here: https://github.com/Yveaux/MySensors_MQTTGateway
You will want to use version 2 of the script.
It does simple note ID assignments by keeping a list of all ids it has seen and choosing the first ID not in this list when receiving an ID request.
There are some dependencies, but you will notice that as you start the script
@kolaf said:
The latest version of domoticz is apparently broken, but I think it compiles with a version from a few days ago... Typical
No, it doesn't 
The latest version of domoticz is apparently broken, but I think it compiles with a version from a few days ago... Typical
@AWI said:
Domoticz
Thanks for the suggestion of Domoticz, I will definitely look into it a bit more closely.
Apart from not being as nerdy, are there any other features that set it apart (above) OpenHAB?
I have been running OpenHAB for a while, and I have it integrated with rfxcom,z-wave, and mySensors (through MQTT). It is working pretty well, and I like the fact that we have configurational files for the bindings and rules. This makes things that much more easy to play with, backup, and restore when something fails :-).
I'm wondering, though, if there are any better alternatives out to back and support this range of hardware? I briefly tried HomeSeer, but I did not like its reliance on Windows. Are there any other platforms of significance I should check out? I have a relatively powerful Linux server running the home automation software, so anything Linux related is of interest.
My requirements: Automation (rules for reacting to events), control through a web page and cell phone, data logging with nice visualisation, and, of course, integration with the hardware I'm using (listed in the first sentence).
If the software is really good I'm fine with its costing some money.
Any suggestions?
@Sparkman Many thanks, but using "or" doesn't allow me to detect if the second switch is pulled low after the first switch is pulled low, since the interrupt will already be low. I was thinking that maybe some kind of XOR function would work since it would change the output whenever any input changes. However, I'm not exactly sure how to implement this, especially not for more than two switches (if the XOR function is even defined for more than two inputs). Also, my arsenal is currently pretty limited, I only have resistors (although I suspect I will have to change this at some point, but not in the middle of Easter).
I have a battery-powered sensor that I want to sleep as much as possible. The trouble is that I have two door sensors that I want to keep track of using interrupts, but only one interrupt pin available (interrupt 0 is used by the radio on my moteino, I think). Is it possible to use the pinChangeInt library to have the sensor wake from gw.sleep() in some way, or is this only possible using the hardware interrupt pins? Is there any other way I can wake on one or more buttons/reed switches using only one interrupt?
Thanks.
@tekka said:
@kolaf are you using the OTA bootloader?
No, I haven't figured out that part yet. I'm not even sure if I have available flash memory for this, nor if this is expected to work with the rf69 radios.
@hek You didn't see any extra node ID requests when the sensor booted?
@reddy11 I had to do the same, although I did the change in the default parameters for the function definition since all my radios are HW :-).
I'm not using the MQTT gateway, I'm using the serial gateway together with a Perl script someone here made which functions as a MQTT gateway, and which I modified to handle node ID assignments.
A bit off topic, but what is version 2.0, and should I be worried?
I might as well continue while I'm at it
Another weird issue I'm having is that every node requests a new ID whenever it starts, but it does not switch to the new ID it receives. It just continues with the old ID it already had.
When I wipe the ROM it requests a new ID as expected, and this time it is saved and used for subsequent communication. Why is it requesting a new ID when it boots, when it already has one?
Glad I could help :-). I guess my prize will be that you patch this so that I do not have to create a pull request 
@hek
As far as I know the function is the interrupt routine that is called by the watchdog when the time expires. I guess it doesn't matter where it is defined so it should be fine to move it. It is not called explicitly anywhere in the code, but by the watchdog. As such, I don't think it should be defined as is done in the header file for the other functions.
My question is why is it not working for me without this code, I assume it has been working for everyone else?
I narrowed it down even further. It appears that there is no appropriate interrupt and present to handle when the watchdog fires. I have no idea why this is the case, and I do not know if this fix is correct, but by a placing this code somewhere in MySensors.cpp everything works nicely:
ISR( WDT_vect ) {
/* dummy */
}My current guess is that the watchdog timer resets the chip after the time period instead of throwing an interrupt to wake the system...?
Please disregard my previous "analysis"/guess. It turns out that the repeating behaviour that was caused by a program crash. The trigger for this crash is MyHwATMega328::sleep(ms) . I'm running a RFM69HW radio on a anarduino board, which should be using the ATMega 328 chip, same as the moteino.
By replacing the call to this function in MySensor::sleep(unsigned long ms) with a simple delay(ms), the crashes no longer occur.
@hek I tried setting up a second sensor (temperature and power supply voltage) with the updated library. I wiped eeprom, uploaded the sketch, and fired it up.
It requested a node ID from the gateway, which it received, and everything seemed to go smoothly until it had transmitted the first data point. After that it immediately enters a request for a new node ID, which it receives, and things go in an endless loop. Here is the log:
find parent
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
read: 0-0-255 s=255,c=3,t=8,pt=1,l=1,sg=0:0
parent=0, d=1
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
read: 0-0-255 s=255,c=3,t=4,pt=0,l=1,sg=0:1
send: 1-1-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
id=1
send: 1-1-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
sensor started, id=1, parent=0, distance=1
send: 1-1-0-0 s=255,c=3,t=11,pt=0,l=20,sg=0,st=ok:Temperature basement
send: 1-1-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 1-1-0-0 s=1,c=0,t=6,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=2,c=0,t=13,pt=0,l=5,sg=0,st=ok:1.4.1
1023send: 1-1-0-0 s=2,c=1,t=38,pt=7,l=5,sg=0,st=ok:5.4
send: 1-1-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:102
send: 1-1-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:20.6
req id
send: 1-1-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
read: 0-0-1 s=255,c=3,t=4,pt=0,l=1,sg=0:3
send: 1-1-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
sensor started, id=1, parent=0, distance=1
send: 1-1-0-0 s=255,c=3,t=11,pt=0,l=20,sg=0,st=ok:Temperature basement
send: 1-1-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 1-1-0-0 s=1,c=0,t=6,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=2,c=0,t=13,pt=0,l=5,sg=0,st=ok:1.4.1
955send: 1-1-0-0 s=2,c=1,t=38,pt=7,l=5,sg=0,st=ok:5.0
send: 1-1-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:95
send: 1-1-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:20.7
req id
send: 1-1-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
read: 0-0-1 s=255,c=3,t=4,pt=0,l=1,sg=0:3
send: 1-1-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
sensor started, id=1, parent=0, distance=1
send: 1-1-0-0 s=255,c=3,t=11,pt=0,l=20,sg=0,st=ok:Temperature basement
send: 1-1-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 1-1-0-0 s=1,c=0,t=6,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=2,c=0,t=13,pt=0,l=5,sg=0,st=ok:1.4.1
956send: 1-1-0-0 s=2,c=1,t=38,pt=7,l=5,sg=0,st=ok:5.0
send: 1-1-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:95
send: 1-1-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:20.7
As far as I can see this should be caused by the node ID still being AUTO, but this shouldn't be the case since it appears to be correctly stored in ROM?
@hek I updated with your latest changes and refreshed my node and gateway (which I am happy to report has run stable since yesterday). Things seem to work out of the box now which is good. There is a small issue, I think, where you could use the GATEWAY_ADDRESS a few more places for consistency, but apart from that I'm quite happy :-).
diff --git a/libraries/MySensors/MySensor.cpp b/libraries/MySensors/MySensor.cpp
index 70d3680..4a87e33 100755
--- a/libraries/MySensors/MySensor.cpp
+++ b/libraries/MySensors/MySensor.cpp
@@ -101,9 +101,9 @@ void MySensor::begin(void (*_msgCallback)(const MyMessage &), uint8_t _nodeId, b
if (isGateway) {
// Set configuration for gateway
- nc.parentNodeId = 0;
+ nc.parentNodeId = GATEWAY_ADDRESS;
nc.distance = 0;
- nc.nodeId = 0;
+ nc.nodeId = GATEWAY_ADDRESS;
} else {
// Read settings from eeprom
hw_readConfigBlock((void*)&nc, (void*)EEPROM_NODE_ID_ADDRESS, sizeof(NodeConfig));@hek
Great. In the meantime I'm doing some stability testing of the current code base.
Okay, I have done some digging.
The gist of my last post was that it received no response for any of the messages sent directly to the Gateway, they never even arrived at the gateway. The only message that arrived was the broadcast message.
The first hints for me was the initialisation string from the gateway. It indicates that it is initialised with the address 255. This is a bit weird, since the Gateway source code provides a value of 0 to gw.begin(). Looking into the source for this it turns out that the value provided here is never stored in the node configuration, and thus is never used as the address for the node. I made some changes to store the address in the node configuration, and suddenly the Gateway started to respond to the messages from the sensor.
As for the acknowledgements, it turns out that ACKRequested never seems to return true even if we use sendWithRetries. If we assume this to be true and transmit acknowledgements regardless (which is correct since we always use send with retries) the status of all the send messages from the sensor revert to "ok".
I guess that this fixed to the acknowledgements issue is good enough for now, but I am definitely not sure about the issues with the Gateway node id. Any thoughts on this would be very welcome.
diff --git a/libraries/MySensors/MySensor.cpp b/libraries/MySensors/MySensor.cpp
index 91644e0..d5badb3 100755
--- a/libraries/MySensors/MySensor.cpp
+++ b/libraries/MySensors/MySensor.cpp
@@ -142,6 +142,13 @@ void MySensor::begin(void (*_msgCallback)(const MyMessage &), uint8_t _nodeId, b
// Try to fetch node-id from gateway
requestNodeId();
}
+ } else {
+ if (_nodeId != AUTO) {
+ // Set static id
+ nc.nodeId = _nodeId;
+ // Save static id in eeprom
+ hw_writeConfig(EEPROM_NODE_ID_ADDRESS, _nodeId);
+ }
}
setupNode();
diff --git a/libraries/MySensors/MyTransportRF69.cpp b/libraries/MySensors/MyTransportRF69.cpp
index b55ce14..3874773 100644
--- a/libraries/MySensors/MyTransportRF69.cpp
+++ b/libraries/MySensors/MyTransportRF69.cpp
@@ -29,7 +29,7 @@ uint8_t MyTransportRF69::getAddress() {
bool MyTransportRF69::send(uint8_t to, const void* data, uint8_t len) {
// Make sure radio has powered up
- return radio->sendWithRetry(to,data,len);
+ return radio->sendWithRetry(to,data,len,5,200);
}
bool MyTransportRF69::available(uint8_t *to) {
@@ -45,9 +45,13 @@ uint8_t MyTransportRF69::receive(void* data) {
// data[i]= (void)radio->DATA[i];
// }
memcpy(data,(const void *)radio->DATA, radio->DATALEN);
- if (radio->ACKRequested())
+ if (radio->ACKRequested() || 1)
{
+ Serial.println("Acknowledgement requested");
radio->sendACK();
+ Serial.println("Sent acknowledgement");
+ } else {
+ Serial.println("Not wanting acknowledgement");
}
return radio->DATALEN;
}