Time awareness and scheduling events
-
@hek I also want to be able to switch on my lights when my gateway is down, but when we want to move intelligence to the nodes (eg make them programmable using rules as seen in another discussion) we have to think upfront what the implications are and how to implement this. I should not rush some kind of schedule rules now, without thinking over the whole concept first.
This is a request for ideas before I start coding any of this!!!
:)
time awareness was straight forward based on existing functionality (even if I would still argue that it should be an integral part of the sensor code and not require separate code in the custom sketch).The rules engine requires much more prep work and smart ideas.In an earlier project I ended up with the following (not saying that this is the best approach - just to start the discussion):
- simple memory manager assigning memory addresses so that you can remotely request or set a variable in memory the same way you do today with sensors (think about a memory address having its own sensor-id on the node)
- rules to set variables on the same node or on remote nodes (or on the gateway/controller)
- rules triggered by schedule or triggered by events (button clicked / temperature changed / ...)
- no need to trigger rules remotely - you can get that by setting a variable remotely and have a rule listening on changes to that variable (node A with the light switch telling node B with the relay to turn on the light)
- gateway is always made aware of what's going on but usually not required for the execution
The problem is that the "setup" of the network and the specific nodes gets way more complex - easy to do for software developers but hard to do for a "normal" user.
-
@hek any plans to setup a "dev_1.5" branch or something similar? If we continue adding major functionality changes to 1.4 it will never get "ready" :)
-
@hek I ordered a few of these -> http://www.ebay.com/itm/191276972230 hoping they can serve the same purpose.
@korttoma said:
@hek I ordered a few of these -> http://www.ebay.com/itm/191276972230 hoping they can serve the same purpose.
I have now been playing with one of these for a few hour and I really like it. Running an LCD and TinyRTC on the same I2C bus and it is working fine.
Need some more time on the sketch before I mount everything in a box. The goal is a scene controller
/ clock / info display by the bed.
I was thinking of adding the knock sensor as a "clapper" device but I don't think I can pull of the code so that it would keep updating the clock as often as I would like.- Tomas
-
@korttoma said:
@hek I ordered a few of these -> http://www.ebay.com/itm/191276972230 hoping they can serve the same purpose.
I have now been playing with one of these for a few hour and I really like it. Running an LCD and TinyRTC on the same I2C bus and it is working fine.
Need some more time on the sketch before I mount everything in a box. The goal is a scene controller
/ clock / info display by the bed.
I was thinking of adding the knock sensor as a "clapper" device but I don't think I can pull of the code so that it would keep updating the clock as often as I would like. -
Probably not something you need guys, but something i did the other day - a sketch to request the time from Vera and set an RTC.
My requirement is to keep the RTC synced when daylight saving changes, so sync would be at 2:01 Sundays.
-
Probably not something you need guys, but something i did the other day - a sketch to request the time from Vera and set an RTC.
My requirement is to keep the RTC synced when daylight saving changes, so sync would be at 2:01 Sundays.
-
No prob... you can remove the bugs ive added ;-)
-
I would suggest to sync times a little bit more because if i remember correct the 1307 is quite sensitive for drifting because of temperature, if it would drift 3 seconds a day would be around 16 minutes a year, the DS3231 compansates this with the build in temp sensor.
But i could be incorrect, but, update your rtc more often anyway ;)
-
Just tried the DS3232RTC library from the examples provided by @hek and it seems like the RTC I2C DS1307 AT24C32 (link to device in earlier post) I have is working happily with this library also. I guess all the features of the library does not work but since the features on my device are working I will stick with this lib since it is provided by MySensors.
Maybe you should try it out to @gregl
BTW!, the RTC I have seems to drift quite allot (~1s/h) so I would not recommend it to someone that needs accuracy.
-
All - help me understand the use-case for a RTC on a sensor please.
From the discussion above I get that we might have two different needs:
- really high accuracy
- a second (or few seconds) deviation are acceptable
We lose accuracy in RF transmission already, therefore fetching the time on the controller or gateway and sending it to the nodes is not appropriate for the high accuracy need. A RTC would not help in this case because you need to tell the RTC the current time to start with and if that's already inaccurate, you won't get the accuracy needed. The only way to get real accuracy would be to fetch it on the node directly e.g. with a DCF77 receiver.
For the "less accuracy needed" scenario why would you add hardware to the node if receiving a time broadcast from the controller every x minutes is good enough to get the required (lower) accuracy "in software" without the need for hardware? -
You would be better of with an http://www.maximintegrated.com/en/products/digital/real-time-clocks/DS3231.html which has a theoretically drift between 1 and 2 minutes a year (depending on operating temperatures).If i'm correct it uses the internal temp sensor for drift compensation (and could also be read?).
-
All - help me understand the use-case for a RTC on a sensor please.
From the discussion above I get that we might have two different needs:
- really high accuracy
- a second (or few seconds) deviation are acceptable
We lose accuracy in RF transmission already, therefore fetching the time on the controller or gateway and sending it to the nodes is not appropriate for the high accuracy need. A RTC would not help in this case because you need to tell the RTC the current time to start with and if that's already inaccurate, you won't get the accuracy needed. The only way to get real accuracy would be to fetch it on the node directly e.g. with a DCF77 receiver.
For the "less accuracy needed" scenario why would you add hardware to the node if receiving a time broadcast from the controller every x minutes is good enough to get the required (lower) accuracy "in software" without the need for hardware? -
All - help me understand the use-case for a RTC on a sensor please.
http://forum.mysensors.org/topic/284/simple-temp-light-time-setup-with-lcd-1-4-no-beta-anymore
Time currently is being pushed every minute by the device created on the controller to "the display" (It has no RTC now). When it fails to receive the new time it would then be standing still. So it is nice to have without power failure.
-
All - help me understand the use-case for a RTC on a sensor please.
http://forum.mysensors.org/topic/284/simple-temp-light-time-setup-with-lcd-1-4-no-beta-anymore
Time currently is being pushed every minute by the device created on the controller to "the display" (It has no RTC now). When it fails to receive the new time it would then be standing still. So it is nice to have without power failure.
@hek @John
using the "time.h" library on the node the time will continue to run. It will not be very accurate (as accurate as the "millis" in arduino) which should be sufficient to turn off the water after 15 minutes (no matter if that's a few seconds off) and good enough to let the clock tick further unless the next successful submission is received from the controller. -
@hek @John
using the "time.h" library on the node the time will continue to run. It will not be very accurate (as accurate as the "millis" in arduino) which should be sufficient to turn off the water after 15 minutes (no matter if that's a few seconds off) and good enough to let the clock tick further unless the next successful submission is received from the controller.
