Posts made by SiLeX

Oh, I didn't know they perform so "bad" in real-life applications. I would love to stay informed so it would be awesome if you could post your success-story here if you got it Very interesting topic indeed.

Good luck!

I understand. There is also a relatively new infrared array sensor, that has a much higher resolution than the default PIR sensors and will be able to detect temperature differences over 64 separate fields and thus human presence.

Here is a link to a typically slightly more expensive but easy-to-prototype breakout board from Sparkfun with the Grid-Eye: https://www.sparkfun.com/products/14607

Might be worth a shot. I am planning to use this for detecting presence without the need for the occupants to be in motion regularly (office spaces, living rooms, etc).

Grid-eye information: https://www.mouser.de/new/panasonic/panasonic-grid-eye-infrared-array-sensors/

If you are going to try a z-wave multisensor, you should look into getting a Fibaro FGMS-001 (https://www.fibaro.com/en/products/motion-sensor/). I tried the Aeotec and the Fibaro and the settings of the Fibaro are way richer. There are 3 settings to tune the PIR detection so that might be interesting to you. Also I never had to change batteries in 2 years.

You can link multiple things (or thing channels) to the same item in openHAB. Simply create one single ColorItem and separate all channels with commas.

Working example:

Color aacc_color "Mysensors LED Lights" (lights) {channel="mysensors:rgbLight:bridge:drawer_lights:rgb,mysensors:rgbLight:bridge:desk_lights:rgb"}

I can absolutely confirm this with VS2015, Visual Micro and MySensors 2.1.1. This is clearly a kind of merging, that is done by Visual Micro.

All includes have to be made BEFORE the first line of code is executed. The initialization of your SENSOR_ANALOG_PINS array is such a line of code.

Just posting it to keep it visible and well-scored at search engines, as this is SOLVED and works fine. Thank you!

I can confirm that the Arduino hangs at the init, if it cannot communicate with the nRF24L01+.

Often had that "issue" when I accidentally disconnected the MOSI cable and the communcation was broken. There seems to be no timeout though. If you enable the MySensors debugging, you will see radio init... on your serial line.

I now use this behaviour as a kind of self-test. In the setup() of my sketches, I turn on an LED, do the radio init and turn it off afterwards. If it stays on, I know there is something wrong with the radio. Without even connecting a single serial cable.

Maybe you can use it this way, too.

Just to clarify: The hang will not happen if you have a bad radio range. It will only happen if the local communcation through SPI fails.

@Lemme said:

Wondering if it is still limited to 8 seconds. Or if I have to do some sort of loop/counting to make it sleep for several minutes or more

If you need longer intervals, you should use SLEEP_FOREVER and attach a Timer interrupt beforehand. Pseudocode would look like this:

loop(){
...
attachInterrupt(Timer1, 600000, dummy_function) // wake up every 10 minutes
gw.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF)
detachInterrupt(Timer1) // disable so we don't interrupt ourselves

.... do things, send data, and so on ......

}

void dummy_function(){
// this does nothing, but interrupt need something to call, so we make a dummy function
// this will return immediately to the loop() again
}

This is best-practise for things that are not real-time-based (like encoder wheels). Using the normal loop makes it possible to use all the millis() and other time-based functions you wouldn't be able to use withing interrupt calls.

By the way - in YOUR case, when you don't want to receive anything on the sensor node while sleeping, using the MySensors Sleep function is perfectly fine. This thread focuses on using it with other interrupts than Timers.

@TimO said:

Something I plan to do, is adding the ACK functionality to the binding, so if no ACK is received the command is repeated for 5 times or so.

+1 for the ack functionality. In my opinion this is a Transport-Layer functionality and should be built into the gateway (Arduino or whatever) itself. But the main developer doesn't like the idea because he is fearful that the serial buffer (or even an arduino queue system) will be unable queue enough messages while resends happen.

On the other hand: we have plenty of RAM on our openhab hosts, so your idea seems like it will solve the problem completely, because we could even react on continous fails with putting the device offline (or whatever the openhab2 terms are for this)

@nikos1671 In case of unhandled messages (when there is no openhab item assigned to this nodeID;childID;-combination in your sensorToItemsMap), they will just be ignored (and print the data field).
This happens here in the code: https://gist.github.com/gersilex/13f39b3419427b35636a#file-default-rules-L211

This will look like this:

3;255;4;0;0;FFFFFFFFFFFFFFFF0300
No item matches nodeId=3, childId=255. Data received: FFFFFFFFFFFFFFFF0300

However, this was never tested with debugging enabled on the Gateway. This is why I asked you to disable debugging and recompile/reupload the code to your gateway arduino without the DEBUG flag inside MyConfig.h.

There is a know problem which is not catched currently:

• Data can only be decoded, if the String has exactly 6 fields, seperated by a semicolon.

Please go and try to disable the DEBUG on your gateway arduino.

Hey guys, on my Raspberry Pi 2 the first rule execution takes about 15 seconds. If you have changed the rules file, the xtent logic has to be re-compiled to java code again. But after the first rule execution it takes only about 10-50ms for execution.

Also, @nikos1671 I would turn off the DEBUG mode on your gateway. Receiving data works and this is what you would debug. You see incoming data without debug, too so you can securely get rid of it

I don't know this specific model, but I can recommend you to use TTL (logic level) types, which are to be used with 5V logic. I use the IRLZ34N with my 5V Arduino UNO and 12V common-Anode RGB Strip of 10 Meters without any issues ever since.

Always go and try to study the data sheet. You don't need to understand the graphs, but you really should understand the voltages between gate and source and how they work together.

If you want to have them turn on and off one after the other (like in the video), you would have to use a dimmable shift register / io expander and feed in PWM for every single light (or stair).

It might be easier to use addressable LEDs. I only know the RGB LEDs, but they are also available in white: https://www.google.de/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=ws2812b+pixel

This way you only need one line of cabling and can put power and data in from one end of the cabling. Of course, they can also be dimmed and everything you can imagine. Libraries for common languages and Arduino are available (for example @ adafruit).

what about https://forum.arduino.cc/index.php?topic=232248.0 ?

I also would like to share my working default.rules + examples with you. Hope it can help someone.

https://gist.github.com/gersilex/13f39b3419427b35636a

Very impressive! I will definately give this a try. Though it may not fit as a central automation system for me, the Observe Nodes and the automatic discovery and history graphs look promising!

Thank you for this!

edit: too bad this is written in C# and Windows-exclusive

@TimO said:

Search for "org.openhab.binding.mysensors" and mark it

Unfortunately I cannot find this in the list. I already added your fork as upstream master and pulled it. Anything else to change in there?

edit: solved by throwing away the openhab2 dev repo and cloning @TimO 's repo richt after installing the OpenHAB IDE. Alternatively you can create a new workspace and import/clone @TimO 's repo from there.

Run a product stays empty, interesting files are in addons/binding/org.openhab.binding.mysensors/ESH-INF/thing/

@rvendrame said:

Adding my two cents, if you keep radio always on and only sleep arduino, at the end of day you didn't save too much, as the radio is usually the most power consuming in the equation...

Thanks for you answer. I am receiving IR commands over MySensors and need to react on them (with IRLib) in realtime. This is a big, 5V Arduino Uno. Interestingly it saves a lot of power if I PowerDown the Arduino. I did this with the RF24Network library in the past and it saved a lot.

Maybe the temporary way could be waking up and requesting every 2 seconds or so. But I would really like to use the LowPower lib again.

@Meister_Petz Did you uncomment #WITH_LEDS_BLINKING in the Arduino/libraries/MySensors/MyConfig.h (here) ?

You could also try to uncomment the INVERSE definition (here). This will light up all LEDs, and turn the off when something is happenind. At least for debugging this could be useful.

If you using mysensors from the development branch, watch out, because the #define names have changed (here).

Hi @TimO . Great work so far. I'd like to join in and extend your module with a lot more S_ and V_ types. Your Github repo code was updated 3 months ago. Do you want to push your commits so I can fork it?

Also another question: Do I need something special or is the default OpenHAB 2 IDE as described on the OpenHAB2 page enough to start?

@BulldogLowell Of course.

sleep() including all overloads always put the Arduino and the radio to sleep, which is not desired. I only want to sleep the Arduino and have it wake up when INTR goes LOW.

I am trying to PowerDown my node and I want the nRF24L01+ to wake up my Arduino when data comes in (INTR goes LOW).
As I could not find any way to use a MySensors function to sleep on the Arduino, I wanted to use LowPower lib's functionality for this.

MyHwATMega328.h:82:6: error: multiple definition of 'enum period_t'
LowPower.h:4:6: error: previous definition here

Both of your header files contain the exact same enum:

enum period_t
{
	SLEEP_15Ms,
	SLEEP_30MS,
	SLEEP_60MS,
	SLEEP_120MS,
	SLEEP_250MS,
	SLEEP_500MS,
	SLEEP_1S,
	SLEEP_2S,
	SLEEP_4S,
	SLEEP_8S,
	SLEEP_FOREVER
};

My simple code is:

	attachInterrupt(digitalPinToInterrupt(2), interrupt, LOW);
	LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
	detachInterrupt(digitalPinToInterrupt(2));

	gw.process();

This opens up two questions for me:

• Is there a MySensors function to PowerDown the node without powering down the radio?
• Is there a way to force to use the LowPower enum. Tried it with (LowPower::period_t)SLEEP_FOREVER cast but it was not accepted as namespace.

Thanks in advance

@hek If I understand correctly: This is what you try to achive by sending back a requested ACK. So this means, to take the whole network into picture, I would have to remember the message I sent (including the request for an ACK from the reciepient) and see if I receive the same message back from the node.

Unfortunately I don't have the recources to build a bigger network with relays. But I think this would be the same like I did here. But with checking the String and much more time. And much less buffering...

Hope someone want's to try this or something similar

Here is a patch of what I have done to the original GatewayUtil.h:

SiLeX@SiLeX-PC /c/c/U/S/D/Arduino> diff libraries/MySensors/examples/SerialGateway/GatewayUtil.h SerialGateway/GatewayUtil.h -pbBc4                           1
*** libraries/MySensors/examples/SerialGateway/GatewayUtil.h    2015-09-04 16:19:18.000000000 +0200
--- SerialGateway/GatewayUtil.h 2015-10-25 00:37:06.482032200 +0200
*************** void parseAndSend(MySensor &gw, char *co
*** 114,129 ****
--- 114,135 ----
      } else {
        #ifdef WITH_LEDS_BLINKING
        gw.txBlink(1);
        #endif
+
+         uint8_t resends = 0;
+         while (!ok && resends < 10) {
                  ok = gw.sendRoute(msg);
+                 resends++;
+                 delay(random(5, 50));
                  if (!ok) {
                                #ifdef WITH_LEDS_BLINKING
                                gw.errBlink(1);
                                #endif
                  }
          }
      }
+   }
  }

  void setInclusionMode(boolean newMode) {
    if (newMode != inclusionMode) {

It is very aggressive for now and may be considered as a proof-of-conept only. This is running on the Gateway. The sensors would need another change. For me this fit's better as I am remote-controlling way more than I receive data from sensors.

Improvements are very welcome.

I could not find it in the code either, but I assume it is described as a feature on http://tmrh20.github.io/RF24Network/

New (2014): Network ACKs: Efficient acknowledgement of network-wide transmissions, via dynamic radio acks and network protocol acks.

The thoughts about the resend drawbacks are interesting. Especially while hopping over multiple nodes we seem to have no easy way to determine if the send was OK or FAILED. At least with hardware, because the neighbor node was okay and this is all the nrf provides.

Regarding the "lost or queued" messages while resending (and thus blocking completely and not running loop(): Messages will be kept in serial buffer. But with 64 bytes we don't have space for many messages anyway. So we should time out after max 500ms of retries (which is a lot in radio world, as you know).

I saw that there acually is a arduino-driven solution for at leat retrying it a couple of times: http://forum.mysensors.org/topic/1424/resend-if-st-fail/9

Do you think it would make sense to provide a new bool send(MyMessage &msg, bool ack, uint8_t retries) for this case? ( I hope I am not overloading any existing function).

At least I will try this this tonight and give feedback about the increased reliability of my PCB-antenna nRF24L01+ modules.

From my perspective it is an absolute must to have this handled by the library, because it is a core feature of nRF24L01+'s and would be relatively easy to implement.

My home automation system should not need to care about the transport layer stuff, but just make use of a reliable transport layer and be notified if sending and retransmission fail consecutively. Even TCP/IP Stack connections just notify the application layer if the timed out.

Can you put this higher on the list and help if possible?

Edit: This is the library where i got this from and it automagically just works https://github.com/TMRh20/RF24Network/tree/Development
Other libraries like the common RadioHead are doing this as well.

@Anduril said:

ok, what is the behavior if there is no ACK coming back? Trying again for several times before discarding the message? How long is the timeout?

We are discussing this topic in http://forum.mysensors.org/topic/2189/serial-api-noack-when-sending-with-ack-failed as well.

Currently MySensors never resends any messages. You have to program it into your serial application by yourself. It would have to wait for an ACK message and send again, if it didn't come back within time.

In the linked thread we are hoping to find a way for implementing this on the hardware of the gateway.

I assume, sending messages with ack are re-sent multiple times. Anyways I don't see how long this is being retried (which IS built in nicely in the RF24NETWORK library, if known).

But something I really think is important is the fact that we only know whether the radio message worked is, when we receive the answer. And the answer unfortunately is exactly what we have sent.

Wouldn't it be nice if we could have the sending node would print the message that was not acknowledged back to the serial console, but with a "2" in the ACK field? This way we could react to problems asynchronously, instead of waiting a couple of seconds for receiving what we have sent. Also it would make it easier for repeating nodes to tell the GW what happened.

Any thoughts about this?