On 02/22/2015 02:06 PM, Roger Binns wrote:
> On 02/22/2015 10:10 AM, russ lyttle wrote:
>> The "natural" language for the Raspberry PI is Python. For Arduino
>> it is C++. I've confirmed that both PERL and Python drop too many
>> messages when using my naif DB with sqlite3, R-PI model A, and Digi
>> xbee s2 radios.
> 
> You didn't say how you structured things, and some details really matter.
> 
> Any kind of database that has durability will have to sync to storage
> at various points, and that storage will be relatively very slow.  For
> SQLite the default is for each statement to be its own transaction,
> unless you explicitly manage transactions.  Consequently each insert
> will block waiting on storage fsync.  There is tweaking you can do to
> mitigate things, but we'd need to know more about what you are doing
> and have done to provide advice.  Not doing anything about this will
> provide dismal performance even on desktops.
> 
> The second part is about dropping messages.  Since you aren't using
> real time operating systems, there will be variability in latency in
> dealing with messages.  The usual solution is to put some sort of
> queue/buffer between message ingestion and message processing to
> smooth over the timing bumps.  It is generally a good idea to also
> split that across multiple threads or processes so that priorities can
> be managed.  Python's GIL is also very relevant.  For the RPi 1 with a
> single core, it isn't going to matter too much, but the RPi 2 gets you
> quad core.
> 
> Roger
> 
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> 
Here goes. This is pretty long for a mail list.

I have a handful of model A Raspberry pi plus some Arduino UNO, Arduino
FIO, and xbee S2 radios. All were left over from another project.

I also have "Raspberry Pi Home Automation with Arduino", Andrew K.
Dennis, PACKT Publishing. I've built the projects in the book, but they
don't scale well. Neither do the Python Xbee libraries I've found.

My one and only R-Pi 2 was on a UPS truck in a wreck on I-40 during the
ice storm. Big sigh.

My project is as follows (all caps for a potential TABLE):

Top level is a BUILDING which has
                EQUIPMENT (hvac units, security&fire, ...),
                ROOMS,
                ZONES,
                LOG_FILES
ROOMS  have
   EQUIPMENT ( tstats, dampers, smoke detectors, etc)

ZONES have
   EQUIPMENT ( ZONE specific items not associated with a ROOM)
   ROOMS,
   NORMAL_SCHEDULE (time of day, setpoint),
   WEEK_END_SCHEDULE,
   HOLIDAY_SCHEDULE,
   LOG_FILES.

Only the schedules and log files may be modified at run time. All other
tables will be read-only.

The application would cycle through each zone performing actions
according to the schedules in effect. It would respond asap to any alarm
in any zone. It should acknowledge user input within 5 sec.
The system cannot drop messages (fire and safety requirement).

Main Controller (xbee Controller) and Zone Controllers  (xbee Router)
are currently R-Pi Model A;
tstats are Arduino UNO ( xbee Router) with pushbutton LCD display;
damper,fan, etc. are Arduino FIO (xbee EndDevice).

Starting point is 10 rooms, 3 zones, 33 end items. Ultimate goal is 21
rooms, 7 zones, ~100 end items.

My first crack at just implementing a bunch of tables and complex
queries didn't come close to meeting time constraints or being maintainable.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 
<http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/attachments/20150222/20fa2dc5/attachment.pgp>

Reply via email to