Best posts made by kolaf

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

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

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?

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).

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 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.

Hi guys,

I have received my Moteinos and anarduinos with RFM69HW radios. The anarduino webpage recommends a radio library called RadioHead which supports multiple radio tips and provides a common API for communication. http://www.airspayce.com/mikem/arduino/RadioHead/

It even supports quite complex things such as mesh networks. It currently supports the following radios:

• RH_RF22 Works with Hope-RF RF22B and RF23B based transceivers, and compatible chips and modules, including the RFM22B transceiver module. Supports GFSK, FSK and OOK. Access to other chip features such as on-chip temperature measurement, analog-digital converter, transmitter power control etc is also provided.
• RH_RF69 Works with Hope-RF RF69B based radio modules, such as the RFM69 module, (as used on the excellent Moteino and Moteino-USB boards from LowPowerLab http://lowpowerlab.com/moteino/) and compatible chips and modules such as RFM69W, RFM69HW, RFM69CW, RFM69HCW (Semtech SX1231, SX1231H). Also works with Anarduino MiniWireless -CW and -HW boards http://www.anarduino.com/miniwireless/ including the marvellous high powered MinWireless-HW (with 20dBm output for excelent range). Supports GFSK, FSK.
• RH_NRF24 Works with Nordic nRF24 based 2.4GHz radio modules, such as nRF24L01 and others. Also works with Hope-RF RFM73 and compatible devices (such as BK2423). nRF24L01 and RFM73 can interoperate with each other.
• RH_NRF905 Works with Nordic nRF905 based 433/868/915 MHz radio modules.
• RH_RF95 Works with Semtech SX1276/77/78 and HopeRF RFM95/96/97/98 and other similar LoRa capable radios. Supports Long Range (LoRa) with spread spectrum frequency hopping, large payloads etc. FSK/GFSK/OOK modes are not (yet) supported.
• RH_ASK Works with a range of inexpensive ASK (amplitude shift keying) RF transceivers such as RX-B1 (also known as ST-RX04-ASK) receiver; TX-C1 transmitter and DR3100 transceiver; FS1000A/XY-MK-5V transceiver; HopeRF RFM83C / RFM85. Supports ASK (OOK).
• RH_Serial Works with RS232, RS422, RS485, RS488 and other point-to-point and multidropped serial connections, or with TTL serial UARTs such as those on Arduino and many other processors, or with data radios with a serial port interface. RH_Serial23 provides packetization and error detection over any hardware or virtual serial connection.
• RH_TCP For use with simulated sketches compiled and running on Linux. Works with tools/etherSimulator.pl to pass messages between simulated sketches, allowing testing of Manager classes on Linux and without need for real radios or other transport hardware.
  ``

Seeing as the radio that is currently supported by MySensors is also supported by RadioHead I was wondering if anyone was interested in helping me porting MySensors to work with the RadioHead library. This will greatly increase the versatility of the MySensors library and magically allow it to work with a range of different radios :-).

I have briefly looked at the MySensors source code and it looks like most of the changes have to be done in MySensors.h and .cpp files.

I am willing to take a stab at it, but as everyone else I am limited on time. Still, it looks like it should not be a very difficult task. As discussed in another thread, it should be sufficient either to subclass the new radio library and replace a bunch of function calls, or drop the subclassing altogether and simply use the radio library as a regular included library.

The obvious difficulty comes soon as MySensors requires a function that is not available in the new radio library. However, seeing as MySensors is a pretty high-level library, and the API support from radioHead seems quite good, I suspect it should be possible to get around any such problems.

Anyway, I'm thinking of creating a branch of the library and spending a few hours trying to port it and get some basic functionality to work. Is anyone else is any value in this it would be great to have some help

@Fwessels I'm glad to see that someone else also finds that transceiver interesting. The source code in the repository is fully usable and up-to-date as a version 1.4+ something (I believe). Still, be aware that this will probably not become an official version since work is ongoing to figure out what is the best way of supporting multiple link layers.

Nevertheless, feel free to use the code in that repository. You can look at the serial gateway to see how a sensor is initiated. Everything is identical to the official 1.4 version except for the initialisation phase where you define the radio driver. You also need to include the Radiohead library in your Arduino installation. Depending on which radio version you have you will have to tweak some of the initialisation parameters (power and frequency). The MQTTgateway has not been ported to work with the Radiohead library, so this is not working in my repository.

Let me know how it goes, and you should keep an eye on the Radiohead topic in the developers forum to see how this develops.

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

For the record there is also this initiative where a smart guy has created a Python Web application to interface between the serial connection and openhab. He has even built in the functionality for handling node IDs.

https://github.com/wbcode/ham

It seems like there are three quite usable options for interfacing with openhab:

1. The MQTT gateway
2. Using the serial binding in openhab
3. Using the python openhab gateway.

The serial binding seems the best option for quick prototyping with its low implementation cost (no additional software) and high flexibility. One of the two other options seems to be a better long-term choice since they will be easier to manage on the configuration size as the network grows, I think. I like the concept behind the python gateway, but using the httpbinding to communicate with it seems a bit cumbersome. Ideally I would like to see this incorporated as an openhab binding, but I do not think it is possible to do the node ID assignment this way since the binding should be stateless.

This leaves the MQTT solution which leverages technology that seems to grow in popularity. An additional benefit is that the author of the software is still around the forums as opposed to the case with the python gateway. The downside is that the item configurations seems a bit complex (at least to me), it is much easier to understand the serial binding or HTTP binding usage.

It is a tough choice.

@Damme Thanks for your input. I have had a chance to debug a bit more this evening and it turned out that I was not initialising the radio correctly.

I now have a version which is working with the RF 69 radio soldered to my Arduinos. Currently it should be easy to change the radio driver by changing the driver that is initialised and changing the appropriate include files.

I have achieved a successful communication from a sensor implementation to the serial gateway implementation where it requests a node ID. This is using the RHMesh manager implementation which handles a dynamic mesh network in the background.

I have not tested return communication yet because am frankly not quite sure what the correct command would be to assign a node ID. I guess all figure this out tomorrow, unless someone cares to give me an example?

With the debug enabled the gateway and simple sensor (simply sending a message every five seconds) amounts to the following when building..

Gateway:

Sketch uses 22,674 bytes (70%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,424 bytes (69%) of dynamic memory, leaving 624 bytes for local variables. Maximum is 2,048 bytes.

Sensor:

Sketch uses 19,854 bytes (61%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,141 bytes (55%) of dynamic memory, leaving 907 bytes for local variables. Maximum is 2,048 bytes.

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

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?

Working on it, fighting git about a rolled back rebase...

@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).

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?