Phillips Hue: How to restore previous state of bulb when using electric switch? - zigbee

I have a number of Philips Hue bulbs at home, but they are only used pretty much like classic on/off-no-color light bulbs today, mainly because I do find electric switches more useful than pulling out my iPhone or correct HueTap just to turn the light on/off. - Every time the Hue bulb is switch off, it forgets its state and always comes back on at 100% brightness in white color.
After lots of googling (and not finding any solutions) I wonder whether I am missing the point and why others do not have this problem.
I am certainly not keen on doing software or even hardware work here, but if I had a reasonable idea I'd love to evaluate such path:
is there anything planned from Philips to fix this? The last firmware update did not help and Philips product support explained that this is not a bug, it is just the way it is designed.
any new "stateful" bulbs?
any work-arounds like patched / custom bulb or bridge firmware?
any recommendation on how to tackle this problem?
Assuming the Hue bulbs themselves do not have any memory installed, I guess they always switch on at 100% brightness and then register with the bridge? And this would be the earliest possible moment to restore the previous state?
Can this problem be solved using Hue SDK? (how long does it take for a turned on bulb to be controllable by the Hue Bridge? What is the quickest way for a Java program to get notified of a bulb being electrically turned on?)
any chance to get the previous state restored in a quicker way if using some ZigBee protocol/techniques directly?
Any hints are much appreciated.
Best regards,
Christian

I agree that it might be irritating that the last state of a light bulb is not being preserved. There is a thread on the developer site of Hue, which gives some insight:
Apparently, there are internal discussions on this topic. The team at Philips hesitates to implement a restore of the previous state due to "security reasons": A user could be left in the dark, if she uses the electrical switch, but the previous state was "off". This opinion has been reiterated in a tweet. There is no definite conclusion in the thread yet.
You can do a workaround and continuously record the state of each bulb, and restore, if necessary. There is a Node.JS script on GitHub that seems to be doing exactly this. If you want to run this as a stand-alone solution, buy a Raspberry Pi (or something similar).
One problem with an SDK based solution is the latency: In my setup, it takes between 3-9 seconds to recognize a light bulb as being switched on and about 20-30 seconds to recognize a light bulb being switched off.
Here is my Python code for monitoring the reachability of my light bulbs, using python-hue-client:
from hueclient.api import hue_api
from hueclient.models.light import Light
from datetime import datetime
from subprocess import call
if __name__ == '__main__':
my_ids = (1, 4, 5) # IDs of my light bulbs
def handle(resource, field, previous, current):
print "{} {}: changed reachability from {} to {}".format(datetime.now().isoformat(), resource.name, previous, current)
hue_api.authenticate_interactive(app_name='test-app')
# register my light bulbs
for id in my_ids:
light = Light.objects.get(id=id)
print "{}: reachability is {}".format(light.name, light.state.reachable)
# Monitor only the reachability of the light
light.monitor(field=lambda l: l.state.reachable, callback=handle, poll_interval=0.1)
print("Starting monitoring. Control-c to exit.")
# Start the monitoring loop
hue_api.start_monitor_loop()

Related

Cannot clone nRF52840 to reproduce low deep sleep current

I currently have firmware that can reach an average deep sleep current of ~130uA. I can reach this level reproducibly on one of the boards I have.
successful deep sleep
Trouble is, when I try to clone this chip onto other chips using the nRF Programmer (Connect) app, I get extremely high power consumption, average of ~20mA at all times, seems the device doesn't reach deep sleep properly. Tried this on several other boards, so I don't believe it's simply a problem of something shorting. Strangely, the application just runs fine, the current is just several times normal for the same functionality.
unsuccessful deep sleep
Does anyone have any ideas on how I can truly clone the flash of one device, onto another? Clearly the "save as file" on nRF Connect isn't doing this. Erasing all and reuploading, starting from a blank chip and writing,
FYI I'm using the nRF52840 module by Raytac (MDBT50Q), implemented on a custom board. This board SHOULD be capable of going down to ~33uA, which I have observed in the past with this very board. By some combination of erasing all, reprogramming, setting the 3.3V logic level(nrfjprog --memwr 0x10001304 --val 5), etc,
For posterity, I did actually find the solution! For anyone else in a similar boat to me, the winning command is:
nrfjprog.exe --readcode --readuicr --readram [filename.hex]
Apparently, the --readram was the winning flag, as without it the sketch simply doesn't run at the same current consumption for whatever reason. But now, I can reproducibly image and transfer identical firmware, which was what I was after.

Some questions for bluetooth low energy as an indoor proximity sensor for building or school campus

My professor recently approved our research paper which will also be used in our final year thesis. Basically our main purpose is to create a system for location tracking and attendance automation for students and staffs. We would like to use the power of bluetooth low energy modules for this project.
I have actually done quite few research about this but I am having trouble which keywords to use in order for me to filter the right answers for my question. So instead, I'll just put all my questions here.
I provided an image to further understand the concept I am talking about.
Basically, the broadcaster/advertisement mode modules are for students and staffs. While the observer mode modules are initially installed in every rooms or spaces in our building/campus.
Broadcast and Observer mode
I would like to clarify first that the location tracking is only basic, it only detects which rooms are the students and staffs located.
Here are my questions:
What is the maximum advertisement/broadcaster module can the observer module detects at the same time?
Our target is about 50 students per room, 300 students in cafeteria, will the observer module have a large amount of latency upon scanning advertisement packets?
Do we have to use different module for observer mode, or will the same module for broadcaster mode be just fine?
Since this is supposedly embedded to school IDs, we would like to use a coin cell battery, how long will it last?
According to my research, BLE range is about 100 meters, but we will be using coin cell battery, is it really possible to achieve 100m for broadcasting and observing? If it is, can we perhaps decrease it by programming?
My apologies for too much question, as this is actually our first time doing applied hardware stuffs due to pandemic. Most of our laboratories are basically tinkercad base. Face-to-face classes are allowed for only medical students for now.
A few answers:
BLE scanners can detect hundreds of distinct broadcasters at the same time. There is no hard limit, but the more broadcasters the longer it will take the scanners to detect each broadcaster.
Most BLE modules support both peripheral mode (broadcaster) and central mode (scanner) simultaneously.
Scanning 50 broadcasters in a single room will easily detect 90% of packets, so if the advertiser is going at 1 Hz it will usually take one second to detect, but sometimes 2-3 seconds of packets are missed.
The indoor range is closer to 40 meters with no walls obstructing the signal. Outdoors with clear line of sight the range is higher. Walls often block signals almost entirely, depending on materials.
A CR2032 coin cell can power a BLE broadcast at 1 Hz and max power for about 30 days.
Creating an embedded solution is cool and valid but just remember that broadcasters already exists as each and every student carries a smartphone with BLE embedded into it and your observer can be any BLE capable device from smartphone through PC with BLE dongle all the way to Arduino and alike.
Your broadcasters (or BLE peripherals as they should be called) will need an Android / iOS app and you will have to deal with working in the background without the operating system stopping your app.
Your observer (or Central in BLE language) can be any stationary PC if such exists in the class which can make development and deployment a lot easier.

What happens before Micro-controller Startup Code being executed? or Power-On/Reset Sequence?

What I know is as below and correct me if wrong, For the automotive bootloader based on any microcontroller, we will have
Startup code (Flash)
Primary bootloader (Flash)
Secondary bootloader (RAM)
As far as a power-on sequence is considered I know that,
From the startup code (provided by the micro vendor, Freescale, ST
Micro, etc.,) the control will be transferred to PBL (Primary
bootloader) using jump or function pointer.
PBL will download the SBL (Secondary bootloader) into RAM, which will
contain the flash driver, capable to download the application.
SBL will download the application into the flash area.
But what will happen before startup code is being executed or just after power on?
I know that each controller will have some sort of code to execute after power on POST (power-on self-test) but still not clear with sequence to operation till bootloader execution comes into execution.
It would be a great help if someone can provide a sequence of operations to reach startup code?
I find it this not uncommon confusion interesting.
POST is software in general, but your question is so vague. Usually when someone talks about POST they are talking about their x86 based computer, that is just software, happens well after the part you are confused about, and is in no way whatsoever required for a computer/processor to run, it has a purpose, adds value so it is there.
Microcontrollers in general do not have primary bootloaders nor secondary, they simply start running your application. Of the dozens/hundreds I have used/examined trying to think of any that have a primary or secondary. Can't think of any off hand. Certain brands in particular do have bootloaders that are usually programmed by them and you cant change or some that you can. How you get into the bootloader varies by brand, often a strap, sometimes a non-volatile bit in a register.
First off processors and the chip around it are dumb, very dumb. Only do what they are told by the humans. Incredibly simple machines. And while the difference between an mcu and a full blown system are at this view pretty much identical, the mcus are simpler and more reliable (for various reasons). The root of the answer starts with the processor or processor core or core or whatever term
might help you. In an mcu this is just one lego block in the whole of the chip, not necessarily even the largest block in the chip. When you look at arm based chips like the stm32 and others with a cortex-m (or older ones with ARMV7TDMI) that lego block is purchased ip from arm, the rest of the chip is either other purchased ip from one or more vendors or in-house made logic. the sram certainly and the flash probably is ip that the chip vendor buys for the specific process on the specific foundry (just like other cell library items, simple gates like AND, OR, NOT and more complicated gates).
Whatever processor core this is, it has an architecture and instruction set. While we know some architectures are implemented using microcode, unlikely that the mcus are, makes no sense the more cisc like might, but the arms and mips and such definitely not. But for this understanding it doesn't matter being microcoded or not there are bit patterns that drive the processor, machine code. We have all heard that chips are made of transistors, and they are. The transistors are part of the simplicity, the basic ones AND, OR, NOT gates you can look up on Wikipedia. You can (inefficiently) build the rest out of those fundamental blocks. A particular instruction tickles the logic, the transistors in a certain way to cause a chain of events, ones and zeros in a specific sequence that do the thing you asked. Logic is not limited to implementing processor instructions, most logic is not part of the decoding and execution of a processor instruction, most if it are equally dumb items. An sram is a lot of packed in bits (four transistors wired up a certain way per bit) with an address and data bus, the logic of an sram lights up rows and columns of these bits when writing or reading. Then there is more logic in front of that sram that decodes an address bus, etc.
As mentioned in the other answer, when power comes up then reset is released, the flip flop based items in the chip which are the registers we read in the manual plus countless others that are behind the scenes are set to their reset value which is done by wiring of the transistors. A number of state machines start which are similar to programs, but are hardwired. wait for reset to go high, once reset goes high then if this input to the state machine is this and that input to the state machine is that then I can move to the next state. The rules to get from one state to the next are implemented in logic. A chip with memory and flash for example might do a bist on the ram first, likely not in an mcu, doesn't make sense, this is logic not software doing this, this is not the post you think of in your laptop/desktop/server. The flash or ram or adcs or other logic might require some number of clocks to settle their logic before reset is released (the reset on the edge of the chip is not necessarily hard wired to all items in the chip, usually it is gated, delayed, etc). So there is a power on state machine that manages this, when the chip is ready then the processor itself will be released, this can be a few or dozens of clock cycles later. The clock itself has to settle, and the logic is designed to wait for that.
When the processor is released from reset it again may have some number of clocks to settle things in its design, it will have a state machine or many that start up the various blocks, and then based on the architectural design of that processor it does one of two things, fetches its first instruction from a known address (address within the processors address space which isn't necessarily the address in the chips view), or it uses a vector table approach and it reads a value from a known address, and that value read is the address of the first instruction and it fetches that instruction. Up to the first fetch there is no software, it is logic.
Depending on how the chip vendor has designed the chip, how they have defined the address space, and understand that addressing within a chip or board design is not some flat universal thing, to the programmer it is, but in reality it isn't. There are many busses with addresses and those address spaces are specific to that portion of the design. When you see the stm32 or others with a bootloader and a strap (boot0/boot1 pin), the logic on the other end of the processor bus may see a fetch at the well known address (meaning both the folks that implement the logic and the folks that write software for the logic know that this is the specific address where things start and if you don't put stuff there it won't boot/work) but as mentioned the chip vendor can do whatever they want with that and often do. As a programmer this can be easily understood as logic isn't any more magical than software:
if strap == 0 return flash_bank_0[address&mask]
else return flash_bank_1[address&mask]
For a certain address range that is decoded in front of this code, but also both banks may be directly addressable:
if address[24]==0 return flash_bank_0[address&mask]
else return flash_bank_1[address&mask]
And this way you can have what you see in the stm32s, that both address 0x00000000 and 0x08000000 or in other vendors chips 0x00000000 and 0x01000000 for example map to the same (flash) memory.
The reason being is that the cortex-ms is vector based, there is a table of addresses that point you at code rather than just instructions at known addresses (like the full sized arms arm7, arm9, arm11, cortex-a). The way you use that is you set your address for reset in the table to be 0x08000000 based so when the processor reads at 0x000000xx it is told to fetch instructions from 0x0800xxxx and it does. When the strap is the other way it finds a different flash which may or may not have a fixed space it may only be visible from the if-then-else. (pretty easy to see with a cortex-m and an SWD debugger and software).
The stm32s will have logic that if the strap is set to run the user application will fetch my guess is four words, if the first one or a specific one is all ones or for some chips all zeros (very often flash/rom resets to ones, because there is a logic in version saving a transistor, so the bit is a zero, but we see it as a one, the bits are all inverted, but this is not a hard and fast rule, just very common) the logic/state machine will, for the stm32 realize there is no user application and will load the bootloader. Now it is very possible the design actually always boots the bootloader and there is software there that looks at the application flash, but I think myself and others on this site decided that is not the case, but none of us work there nor have the visibility into the design. In either case the processor then starts executing what it finds and it is very dumb it is told fetch from this address and it does, the programmer had to make sure that stuff is at that address, and each and every instruction has to be laid out in order properly like train tracks, any gaps or mistakes and the trail goes off the rails, otherwise the train is stupid it just follows the tracks. As humans we call the software post or bootloader or application or whatever. It is just software. Once the processor is started if some software loads and runs other software the processor doesn't know it is stupid it just keeps performing the instructions it is fed as it rolls down the track.
Short answer:
Power ramps up to a chip specified level. At a chip specified time reset should be released. This releases state machines to get the chip ready as needed and release the processor. The processor based on its design either fetches its first instruction from a known place or it reads from a known place and that user planted value is the address where the first instruction lives. After that per the architecture of the chip the execution of that first instruction and fetching of more based on that instruction continue until it crashes or is turned off or put in reset.
There is no magic.
There are a number of good open cores out there that you can simulate with free tools and see (with free tools) the internal signals that make that chip work, you can see the post reset activity leading up to the first fetch and then all the execution from there.
Without knowing which microcontroller you are using, this should be general enough:
The hardware in the microcontroller resets several registers to their documented values. This includes the PC, the program counter.
If the microcontroller has configurable reset vectors the value can be chosen from a few alternatives, other controllers always use the same value.
The code at the location the PC points to is the startup code.
Note: It's always a good idea to read the data sheet of the controller!

How to make a pulse sensor Waterproof ? Or is there any waterproof pulse sensor?

Hi there this might sound stupid but please help me . Does anyone know how to make a pulse sensor a waterproof and water resistant one ?
If you're referring to heartrate sensors like those on pulsesensor.org, the simple answer is no.
There are two issues here. The first is whether the circuit could be fully waterproofed - the answer to this is yes. The second is harder, however - which is whether the sensor you refer to would be effective under water.
These sensors use a green light to detect changes in bloodflow, and they work poorly underwater even in commercial sensors. They are very sensitive to being jostled by water, and lose accuracy when there is water between the sensor and the skin.
There's a useful in-depth discussion of this here:
https://www.yourswimlog.com/best-waterproof-heart-rate-monitors-for-swimming/
If you need to measure heartrate underwater, you might have better luck with a chest strap sensor. These work by sensing elongation of a strap wrapped around the chest, and calculate heartrate based on those changes. Commercial versions are readily available and work well.
If all you're worried about is waterproofing the circuit for shallow water, this can be accomplished pretty easily. All elements would need to be encased in fully waterproof material. You could simply slip the whole thing in a waterproof baggie (google 'dry sleeve' or 'acquapac), or if you're up to it, build a silicon mold to encase the project.

Arduino replace old relays

I have some old relays that controlls an hydraulic motor.
I want to control it with my Arduino. Is this possible?
The relays used are:
DIL 00 52 from klockner moeller.
this is the situation:
I have experience with the arduino but not that much about electrical schemas?
Is there someone that can help me?
Is this equipment functional now?
The part you have pictured looks like it is for an engine lathe, not a pump.
The amount of rust in the box and corrosion on the overloads and relay would make me think that it has run either outdoors, or in a corrosive environment for quite a while with the door open. Why would you run it with the door open?
Because you have to continually reset the overload and or adjust the timer, or tap on the contacts to get them to engage. Either way, this thing is a mess.
The relays you have shown will interface easily with your arduino, but I WOULD NOT replace what's in the cabinet with these.
The set up in this cabinet is for three phase power. The one on top is the main contactor, and the two side by side units are for reversing the motor. Something you don't want to do with a pump.
My advice to you is to find an electrician before going any further with the power end of this project.
it is possible but probably that relay won't fit the load.
You have to be sure to use relay that can sustain at least the same load and spike current (and voltage), or you many bad thing may happen, like melting togheder the relay contact or burn your house down.
i can't see the code on the relay in the second picture, neiter you had given the load information, so i can't help you more.

Resources