{"id":2379,"date":"2017-04-04T15:25:47","date_gmt":"2017-04-04T15:25:47","guid":{"rendered":"http:\/\/grodansparadis.com\/wordpress\/?p=2379"},"modified":"2017-04-04T15:25:47","modified_gmt":"2017-04-04T15:25:47","slug":"the-vscp-sync","status":"publish","type":"post","link":"https:\/\/grodansparadis.com\/wordpress\/?p=2379","title":{"rendered":"The #VSCP sync"},"content":{"rendered":"

\"\"<\/a><\/h4>\n

Sync<\/u><\/h4>\n

To ask for readings (measurements\/sensor values) from nodes one can use CLASS1.CONTROL, Sync<\/a>. One can use sensor index, zone, subzone as a way to tell which readings are of interest. A node should send the requested value immediately when it get a sync. For cashing, use tables or variables to store the readings.<\/p>\n

The sync’s primary use is to synchronize sensor readings from multiple nodes in time but it can obviously also be used\u00a0 just to request data.<\/p>\n

You can see that modules from Grodans Paradis AB<\/a> implement the sync<\/strong> but also have registers the data can be read from and automatically repetitive delivery of sensor data.<\/p>\n

For the Kelvin 1-Wire module<\/a> for example the sync has the following description<\/a><\/p>\n

If a SYNC<\/span> event is received by the module it will check the zone\/subzone parameters of the event and send out temperature measurement event(s)<\/a> for all sensors that match. This can be a handy feature to use of one want synchronized data from several sources.<\/p><\/blockquote>\n

But you can also instruct the module to output temperature sensor data with a set time interval (see report interval registers here<\/a>) or read the temperature reading in a register (see temperature registers here<\/a>).<\/p>\n

Periodical events are perfect when the VSCP daemon<\/a> is part of a system. Tables and remote variables is two features it have that is well suited for this type of sensor data.<\/p>\n

Tables is being rewritten and extended from the functionality available in the last release at the moment and is mostly into place in the head code right now. There is a description here<\/a>. One can do many things with sensor data in them and actually create user defined SQL databases if one like that which can have its data requested over REST\/TCP\/IP\/websockets…<\/p>\n

If one want the x last readings the static table<\/a> is perfect as it works in a round robin fashion.<\/p>\n

One can also use remote variables<\/a> to store certain sensor data. In many of my setups I use them all the time. A typical sample is a sensor value that should be sent on specific intervals to a cloud service but where internal systems need this sensor value at a much higher rate than the cloud service need it. The easiest way to do this is to store the value in a variable <\/a>with a DM entry when it is received. This way one have the sensor value accessible all the time and\u00a0 request the latest value over any of the interfaces. To send the value to a cloud service one use one of the internal events for example the minute event<\/a> and send the value there calling an external script or using one of the internal actions such as the http put\/get\/post action<\/a> or even the run internal JavaScript action<\/a> (soon LUA to).<\/p>\n

Well that’s power for you!<\/p>\n","protected":false},"excerpt":{"rendered":"

Sync To ask for readings (measurements\/sensor values) from nodes one can use CLASS1.CONTROL, Sync. One can use sensor index, zone, subzone as a way to tell which readings are of interest. A node should send the requested value immediately when it get a sync. For cashing, use tables or variables to store the readings. The […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[13],"tags":[],"class_list":["post-2379","post","type-post","status-publish","format-standard","hentry","category-vscp"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4raCZ-Cn","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/grodansparadis.com\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/2379","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/grodansparadis.com\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/grodansparadis.com\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/grodansparadis.com\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/grodansparadis.com\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2379"}],"version-history":[{"count":1,"href":"https:\/\/grodansparadis.com\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/2379\/revisions"}],"predecessor-version":[{"id":2381,"href":"https:\/\/grodansparadis.com\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/2379\/revisions\/2381"}],"wp:attachment":[{"href":"https:\/\/grodansparadis.com\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2379"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/grodansparadis.com\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2379"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/grodansparadis.com\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2379"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}