Time awareness and scheduling events
-
As started here.
Looking at the TimeAwareSensor example essentially everything is there for time synchronization. Once the callback is set with the initial call to requestTime, any subsequent time packets received from the gateway would be used to update/adjust the internal time accordingly.
The only adjustments needed to get to a real time synchronization would be to let the gateway (or rather the controller) broadcast the time every x minutes and ensure that the sensor listens to the time packets even if they are not addressed to the nodeID but broadcasted (today only TIME packets addressed to the specific node are handled).I've done these changes here and will do some testing.
To schedule events the question is how to store the schedule with a minimum footprint in EEPROM. Keeping hour:minute should be sufficient. Storing these in a byte each is a waste of space (only 5 bits for 0-23h and 6 bits for 0-59m needed or 11 bits for 0-1439m). Looking at usual scenarios you need a bitmap for the weekdays (schedule for Mo/We/Fr only) which takes another 7 bit. With that three bytes are minimum and leave 6 bist for additional purposes.
For home automation you would usually want to have a way to tell if the event should be executed on a public holiday (1 bit) and you want to have a way to tell if it should be executed when you are on vacation (1 bit) - I'll explain in a later post how public holiday and vacation could be determined.Each event should probably include some kind of payload (what to do). To keep this simple I'd propose a single byte payload and let the callback function in the main sketch decide what to do with it.
This is a request for ideas before I start coding any of this!!!
-
I am searching for a way to receive atomic clock... to no success do far...
-
@epierre You lose accuracy during RF transmission to the nodes, therefore I didn't go for DCF77 but told the controller (RPi) to fetch the time via NTF from the internet. If you really need DCF77 then have a look here - should be pretty easy to implement on the gateway and send to sensors from there or even on specific sensor nodes that need very accurate time.
-
I've ordered a couple of RTC modules that could be a optional accessory for a node. Distributing server time is still needed.
-
@hek I ordered a few of these -> http://www.ebay.com/itm/191276972230 hoping they can serve the same purpose.
-
The only disadvantage I see with these modules is that their libraries eat a lot of memory.
I wanted to use them in combination with an lcd but at this point it is either one or the other but not both...
I hope that flash memory will bring some relief...
-
@ToSa maybe I'm missing something but if I understand you right you require scheduling at the sensor, right?
-
@Yveaux Right - I mentioned the garden watering in another post - I want the sensor to be aware of the schedule to reduce the single points of failure to a minimum - and avoid bad surprises getting back home after vacation
That means the sensor is able to execute even if the controller is broken or the gateway is broken or the network connectivity is broken due to a relaying node in the middle etc.
-
The trend in HA now moves towards pushing some of the "intelligence" to the nodes. This creates autonomous units that can actually work for a while without contacting and relying on the "mothership".
-
@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.
-
Fully agree. That why we're discussing the concepts
-
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 yeah yeah... The initial post sounded quite concrete and is limited to time and scheduling. Therefore I wanted to broaden things a bit. But I guess this will automatically happen in a few hours anyway, if you get what I mean
-
@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"
-
Yes, only ONE page left to document (API). Then I'll release 1.4 (push it to master) and we can have development for our selves again
-
@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.
-
Yes, received mine yesterday but haven't had time to play with it yet.
The DS3231 I got seems to have a build-in temp-sensor also.
-
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
-
Thanks! @GREGL I find it useful also for my project.
-
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?).
-
@ToSa said:
All - help me understand the use-case for a RTC on a sensor please.
If your mains powered watering node has a power failure (restarts) and loses connection to controller.
-
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.
-
@ToSa
True, I personally will be using some self build wall clocks, and the display will get a bigger role in our household, so it would be nice to keep track of time as close as possible.
-
@ToSa
In my use case its a pool controller I use a rtc to do several things..but the desire to sync is really just to adjust for daylight savings changes.
