Trying monitor of sensors through smartphones


 
Thread Tools Search this Thread
Top Forums UNIX for Beginners Questions & Answers Trying monitor of sensors through smartphones
# 1  
Old 06-15-2018
Trying monitor of sensors through smartphones

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
Login or Register to Ask a Question

Previous Thread | Next Thread

8 More Discussions You Might Find Interesting

1. Infrastructure Monitoring

Searching for Saas Monitor service which monitor my servers which are sitting in different providers

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)
Discussion started by: umen
1 Replies

2. Hardware

Fedora 16 dual monitor - dual head - automatic monitor shutdown

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)
Discussion started by: wakatana
0 Replies

3. UNIX for Dummies Questions & Answers

Sensors Explanations

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)
Discussion started by: Mat_k
0 Replies

4. Shell Programming and Scripting

Need help with Expect script for Cisco IPS Sensors, Expect sleep and quoting

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)
Discussion started by: genewolfe
1 Replies

5. UNIX for Dummies Questions & Answers

Sensors in terminal?

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)
Discussion started by: fvs
3 Replies

6. Shell Programming and Scripting

Monitor: Read from the monitor

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)
Discussion started by: mig8
2 Replies

7. Shell Programming and Scripting

not able to monitor the process

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)
Discussion started by: infyanurag
8 Replies

8. Solaris

PC monitor

In order to use a regular PC monitor would I need to do any configuration changes to my Ultra 5 box running Solaris 8 ? (1 Reply)
Discussion started by: mangolinux
1 Replies
Login or Register to Ask a Question
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)