I'm looking for away to wake up a node programmatically, but I don't even know if it's possible.
The Context : I wrote a nodejs application that aim to interface z-wave modules thanks to node-openzwave-shared .
Every things works fine with lights but I recently got a PIR sensor that is sleeping directly when I start my nodejs application.
Does anyone know how to wake up my PIR sensor programmatically ? (I can wake it up by pressing a physical button but this solution does not satisfy me)
NB : What is the difference between a sleeping node and a awake node ? (I mean technicaly speaking) It'seems that sleeping node can't receive controller command but can anyone confirm this please ?
Sleeping devices can't be woken up pro grammatically, but most offer settings that can be changed to periodically wake up and provide updated sensor data as well as accepting commands.
I have a battery powered motion/light/temperature/humidity sensor that does that. It wakes on movement or provide a status update every 10 minutes.
Sleeping, on z-wave, just means non-responsive. From a device standpoint, it probably just means a powered down transmitter/receiver.
Related
I am developing a custom watchdog driver for the Beaglebone black SBC. There is an external entity connected to the BBB. It will reset the board if it wont receive a GPIO state change from the BBB within a certain time, that is settable through I2C. From what I have understood so far is that from the Linux software point of view, the /dev/watchdog device should be written to in order to refresh the watchdog peripheral, that's clear. Such thing could be done by the watchdog daemon: https://www.systutorials.com/docs/linux/man/8-watchdog/
The problem here is that it seems that the refresh interval is hard-coded to 60 seconds. For my application the interval is a lot shorter (about 5 seconds typically) and is settable (from 1 to 10 seconds). In this case I think I would not be able to use the watchdog daemon for the custom wdg driver.
Is there a way around this? Or is my take on this case not even correct?
Typically, if you want to use kernel watchdog framework, you can simply write some C code which is petting /dev/watchdog file with your own "watchdog frequency". There is no reason to use watchdog daemon if you have your own reasons.
And, the kernel watchdog framework is hooked into real hardware watchdog which is capable to detect lockup, and generate event based on expiration and if your hardware watchdog "timeout" or "expiration" interval can be tunnable, you can change the time and you can make not to fire for 60 seconds.
Normally, nobody is dealing with watchdog process which is provided by busybox or some other linux pkg. Most likely they are using it as it is. Also, as far as I remember, it is 1 seconds interval.
I am creating the offline application require the user to clock in and clock out in a offline scenario. The problem I am facing here is that how can I make sure the user not messing up the date/time setting in the device and faking the clocking time.
One solution would be to check device uptime (time the device is on). I'm sure you can do it on iOS (see how here), please check if it's possible on your other platforms. You can get the device uptime at the beginning of the work and at finish to get total work time. Problematic scenario would be when the user restarts the phone, since the uptime would reset.
I'm working on an embedded linux platform.
When I do "echo "mem" > /sys/power/state", system will suspend.
I know that kernel and driver can know that suspend operation's coming. But would it be possible that a user space process or application can get the notification that the system will suspend? How?
For example, I have an application who writes 'A' continually into a buffer whose start address is given by a device driver. Would it be possible that this application be notified that the system will suspend so that it could replace all this buffer with 'B' so that when driver is resumed, all what driver sees are 'B'?
Thanks a lot.
Been searching for the same thing. But unfortunately, I didn't find any user space notification during suspend/resume. Applications are just refrigerated/frozen and they will never know they are suspended.
However, one possible approach would be to add a generic netlink message sending or uevent from any driver's suspend/resume function that you can modify. Still the application may never get enough time to process it before it is frozen and might lead to race conditions. Say it received the suspend message and got frozen before it could process it. And once resumed, it will be processing the suspend message.
IMO, it is better to handle the scenario in the driver. Leave the user space alone.
I'm not sure whether it's useful for you in particular, given the mention of "embedded", however systemd can notify you over DBus: https://www.freedesktop.org/wiki/Software/systemd/inhibit/
I'm writing a set of Linux framebuffer applications for embedded hardware. The main application runs on tty1 from /etc/inittab (for now it's just a touchscreen test) and is supposed to run permanently. The second application is executed from acpid when the power button is pressed, and it's supposed to ask user if he really want to shut the device down, and read user answer from a touchscreen. What I want is that the second application would takeover framebuffer while it runs, and then release it and restore the state of screen, so the main application can continue without restart.
Is this scenario possible with 2 different applications, and how should they interact ? Now the second application just can't draw anything while the main application is running.
I know I can kill and restart main application, or move poweroff notification to the main application and have acpid just sending a signal to it, but those solutions don't seem to be optimal.
One solution would of course be to have THREE applications, one that does the actual framebuffer interaction, and the other two just sends messages (in some form, e.g. through a pipe, socket or similar). This is how "window managers" and similar usually works (but much more complicated, of course)
I'm a student on a hogeschool in the Netherlands. We're working with the LEGO Mindstorms NXT for a project.
However, I'm using my phone (minddroid and other applications) to drive the NXT, but I don't know how to simultaneously run a program.
For example, I drive it over a black line with the remote, and because the program is running, the sensor sees in the program that if it drives over a black line, it has to stop.
Is your question how to get the NXT to both communicate on bluetooth and monitor the line at the same time? If so:
Then there are two general solutions:
Main Loop
In your main loop, first check for communications from the bluetooth system, and then check the sensor to see if the black line is detected. Then repeat.
Interrupt
In this solution, the main process would handle communications with the Android phone. The line sensor would be setup to cause a program interrupt when it detects the black line.
The interrupt service routine (ISR) would either set a flag to indicate that the robot should stop or would directly stop the robot.
Choosing which of the above solutions you choose is often dependent on the features of your operating system.
PS It could also be that I'm not understanding your question correctly. In that case, never mind...
No I meant that I wanted to run a program simultaneously with the bluetooth remote.
But I solved it, I connected the nxt with a mobile app, so I could only send direct commands. I solved it by connecting with the program, not the nxt robot.
Thanks anyway!