I was able to enable the Mosquitto MQTT using instructable
Now I need to communicate my new wireless sensor to communicate with Mosquito in such a way that it will display tracker in which it shows the readings of sensor,
Also need to know how can to display the notification on smartphones whenever there will be some disruption takes place in defined ranges
But I am new to this are so need your suggestion and better solution which help to make it functional
Sorry if this is the wrong forum
Searching for Saas Monitor service which monitor my servers which are sitting in different providers .
This monitor tool will take as less CPU as possible , and will send info about the server to main Dashboard.
The info I need is CPU / RAM / my servers status (... (1 Reply)
Hi, I am experiencing troubles with dual monitors in fedora 16. During boot time both monitors are working, but when system starts one monitor automatically shut down. It happend out of the blue. Some time before when I updated system this happend but then I booted older kernel release and... (0 Replies)
Hello,
I am trying to get some information from the sensors on my pc. But i get confuse with what i get.
I don t know where to find out which sensors watches what..
I use "sensors" under ubuntu 10.10.
Here is the result of the cmd line sudo sensors.
the temp 3 indicates 79°C which... (0 Replies)
This Expect script provides expect with a list of IP addresses to Cisco IPS sensors and commands to configure Cisco IPS sensors. The user, password, IP addresses, prompt regex, etc. have been anonymized. In general this script will log into the sensors and send commands successfully but there are... (1 Reply)
I just installed lm-sensor in my terminal and it's working, however i really don't know how to analyze what I have, Any help will be appreciated, Thanks
Here is the reading in my terminal,
sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +40.0°C (crit = +124.0°C) ... (3 Replies)
Hello,
I would like to write a script that use the display as an input.
In the display there is a list of file. I want to use it as an array and this would be the input in my script. Does somebody know how do I make it? (2 Replies)
hi all
I am running a script monitor using source command.
the shell script monitor is used to execute a pl/sql procedure.
when i do
source monitor
and then
ps -ef | grep <procedure name>
i do not get any info
but when i do
sh monitor
and then
ps -ef | grep <procedure name>
i... (8 Replies)
SoDataSensor(3) Coin SoDataSensor(3)NAME
SoDataSensor -
The SoDataSensor class is the abstract base class for sensors monitoring changes in a scene graph.
If you need to know when a particular entity (as a field or a node) changes, subclasses of SoDataSensor can be used to monitor the entity
and notify you when it changes.
SYNOPSIS
#include <Inventor/sensors/SoDataSensor.h>
Inherits SoDelayQueueSensor.
Inherited by SoFieldSensor, SoNodeSensor, and SoPathSensor.
Public Member Functions
SoDataSensor (void)
SoDataSensor (SoSensorCB *func, void *data)
virtual ~SoDataSensor (void)
void setDeleteCallback (SoSensorCB *function, void *data=NULL)
SoNode * getTriggerNode (void) const
SoField * getTriggerField (void) const
SoPath * getTriggerPath (void) const
void setTriggerPathFlag (SbBool flag)
SbBool getTriggerPathFlag (void) const
virtual void trigger (void)
virtual void notify (SoNotList *l)
virtual void dyingReference (void)=0
Protected Member Functions
void invokeDeleteCallback (void)
Additional Inherited Members
Detailed Description
The SoDataSensor class is the abstract base class for sensors monitoring changes in a scene graph.
If you need to know when a particular entity (as a field or a node) changes, subclasses of SoDataSensor can be used to monitor the entity
and notify you when it changes.
Constructor & Destructor Documentation
SoDataSensor::SoDataSensor (void)
Default constructor.
SoDataSensor::SoDataSensor (SoSensorCB *func, void *data)
Constructor taking as parameters the sensor callback function and the userdata which will be passed the callback.
See also:
setFunction(), setData()
SoDataSensor::~SoDataSensor (void) [virtual]
Destructor.
Member Function Documentation
void SoDataSensor::setDeleteCallback (SoSensorCB *function, void *data = NULL)
If an object monitored by a data sensor is deleted, the given callback function will be called with the given userdata.
The sensor priority setting does not affect the delete callback. It will be called immediately, before the object is deleted.
SoNode * SoDataSensor::getTriggerNode (void) const
Returns a pointer to the node causing the sensor to trigger, or NULL if there was no such node.
NULL will also be returned for sensors which are not immediate sensors (i.e. with priority equal to 0), as the result could otherwise be
misleading (non-immediate sensors could have been scheduled and rescheduled multiple times, so there wouldn't be a single node responsible
for the sensor triggering).
The result is only valid within the scope of a trigger(), so if you need to use the pointer outside your sensor callback, you must store
it.
See also:
getTriggerField()
SoField * SoDataSensor::getTriggerField (void) const
Returns a pointer to the field causing the sensor to trigger, or NULL if the change didn't start at a field.
Only valid for immediate sensors (will return NULL otherwise), for the same reason as described for SoDataSensor::getTriggerNode().
The result is only valid within the scope of a trigger(), so if you need to use the pointer outside your sensor callback, you must store
it.
SoPath * SoDataSensor::getTriggerPath (void) const
Returns a pointer to the path from the node under the surveillance of this sensor (either directly or indirectly through a field watch)
down to the node which caused the sensor to be triggered.
Will only work for immediate mode sensors, for the same reason explained under getTriggerNode().
The resulting path is only valid within the scope of trigger(), so if you need to use the path outside your sensor callback, you must store
the pointer and call SoPath::ref() to avoid its destruction at the end of SoDataSensor::trigger().
void SoDataSensor::setTriggerPathFlag (SbBoolflag)
This flag indicates whether or not the path should be queried whenever a node triggers the data sensor.
This flag is provided because finding a node path through a scene graph is an expensive operation.
See also:
getTriggerPathFlag(), getTriggerPath()
SbBool SoDataSensor::getTriggerPathFlag (void) const
Returns whether or not any node induced trigger operations will make the sensor find the path of the node which caused it.
See also:
setTriggerPathFlag(), getTriggerPath()
void SoDataSensor::trigger (void) [virtual]
Trigger the sensor's callback function.
Reimplemented from SoDelayQueueSensor.
Reimplemented in SoFieldSensor.
void SoDataSensor::notify (SoNotList *l) [virtual]
Called from entity we are monitoring when it changes.
If this is an immediate sensor, the field and node (if any) causing the change will be stored and can be fetched by getTriggerField() and
getTriggerNode(). If the triggerpath flag has been set, the path down to the node is also found and stored for later retrieval by
getTriggerPath().
See also:
setTriggerPathFlag()
Reimplemented in SoPathSensor.
void SoDataSensor::dyingReference (void) [pure virtual]
This method is called when the entity we are connected to is about to be deleted.
void SoDataSensor::invokeDeleteCallback (void) [protected]
Runs the callback set in setDeleteCallback().
Called from subclasses when the entity we're monitoring is about to be deleted.
Author
Generated automatically by Doxygen for Coin from the source code.
Version 3.1.3 Wed May 23 2012 SoDataSensor(3)