I noticed that the accelerometer is part of the event kit, so I plugged it in alongside a button and tested the button. The button correctly sends a click event back to the websocket. But the accelerometer does not send anything - even if I shake it. How do I get it to create events?
Is it plugged into the I2C socket? It’s not next to where the buttons go.
I made the same mistake with my light sensor at first.
Yes, it is plugged into the I2C and I can get measurements from it using GET requests. But polling it all the time doesn’t work for me, I’d rather receive an event.
I understand now. I thought that you were asking a different question.
My impression is that you’ll have to do this via software, either programming it (in Arduino mode) to repeatedly monitor the sensor and send alerts under particular conditions, or getting a service like ifttt to perform that for you (which would seem to involve more power consumption, but I could be wrong).
I had likewise been hoping for the options of event-triggered signals and controlling the interval between reports (i.e. having it put itself to sleep for an hour). If you figure either of these out before I do, I would be interested in hearing how you did it.
I’m hoping the Wio team reads these messages and respond. Since they already have events working for buttons and magnetic proximity, i’m sure it will be fairly easy for them to add events for other things. Using events over polling is sure to make a huge difference in the way we use the Wio plugins. An even more powerful event structure would be waking the Wio Wi-Fi interface up from low-power sleep if some significant event occurred and then transmitting that - but I think we are probably pushing the limit of what the seeed team are capable of there… 
Hi all,
Thank you for advising and good discussion here. Yes, it’s easy for us to add event for particular grove. But the limitation we have here is that the grove system can only transfer interrupt to host MCU with GPIO line(either I2C nor UART). All I2C groves will have to drop the interrupt info although that device can fire interrupts. Though the host can poll the events from I2C devices the polling will increase the load of host. Also, this will let the driver more complicated and abuse of this will possibly throw the main task (handling wifi transmission) into disorder. So we give the control of posting polled events to user with a mechanism named ULB - user logic block. ULB will allow the users insert a piece of code into the main loop. Users can do polling and decide if to post an event to server when some condition happens. The status of ULB is, backend ready, web-based frontend under dev. Can have a glance here seeed-studio.github.io/Wio_Link/ … on-the-fly
This is a very good point, but the same limitation is here, if we have known that we will use the interrupt from a button to wake up Wio Link, we can connect the GPIO of that button to the external wake-up IO of esp8266, but actually we don’t know which pin from which Grove socket will be used to wake up Wio Link. Maybe this is part of different between making a generic platform working for several hardware combinations and making a particular product working for fixed hardware schematic. Also, WiFi in a sense is not the best technology for low power consumption field use. We even argued about if to put the battery socket onboard in the design phase. Finally we defined the application area of Wio Link as IoT building - which means Wio Link should be deployed inside or nearby a building from which Wio Link can easily get power from an AC adapter. For those have to use Wio Link with battery, they have to charge it every 1~2 days.
There could be much more improves we should do. If you have any technical advices, please don’t hesitate sharing
Hi xuguang.shao, thanks for that - that was very informative. I think using the ULB method may be the answer to all my problems 
The documentation is fairly clear, but I was wondering if you could help me with one thing:
Where do I find the names and parameters for functions of the installed grooves? By that, I mean the functions created by OTA phase 1.
To be more specific, for my present project I’d like to obtain the temperature from the temperature sensor as well as the data from the humidity sensor. How would I do that in the C++ code?
Thinking ahead a little bit also: Is it possible to put the Wio to sleep from within the C++ code too? What I was hoping to achieve was a ULB that checks the current temperature and humidity. If the temperature is over a certain value or the humidity is below a set level, I will send a WebSocket event and stay awake to allow more commands (activate relay to turn on water). If it isn’t over the threshold, then I will simply go to sleep for a minute, powering the Wio right down and dramatically increasing the battery life. I was hoping to put the Wio in a greenhouse (which is well within WiFi range, but not powered) and keep the battery charged via a small solar panel.
What do you think? Is it doable? Would be pretty awesome
Hi bjarne,
We were planning to provide coding assist in the web based frontend. For now, you have to find the functions in source code here github.com/Seeed-Studio/Grove_Drivers_for_Wio and find the class instance name with any of the following method
a) API call
curl iot.seeed.cc/v1/cotf/project?ac … 32dd8277b2
you will get a response like this
{
“./Main.h”: “#ifndef MAIN_H\r\n#define MAIN_H\r\n#include “suli2.h”\r\n#include “grove_generic_digital_in_gen.h”\r\n\r\nextern GenericDIn *GenericDInD1_ins;\r\n#endif\r\n”,
“./Main.cpp”: “#include “wio.h”\n#include “suli2.h”\n#include “Main.h”\n\nvoid setup()\n{\n}\n\nvoid loop()\n{\n\n}\n”
}
In this example, I configured Wio Link to drive the “generic digital input” device. The instance of the driver class is GenericDInD1_ins and then find member functions of this class here github.com/Seeed-Studio/Grove_D … gital_in.h
b) API reference page in app
From the API url , e.g. 192.168.31.2/v1/node/GenericDIn … 76056505c8, the section after /node/ is GenericDInD1, then add a suffix “_ins” to it, you will get the instance name GenericDInD1_ins
Having the instance name and its member functions, you can program ULB like this
[code]uint8_t input;
void loop()
{
…
GenericDInD1_ins-> read_input(&input);
if(input > 0) …
…
}[/code]
To put the Wio to sleep in ULB, you can call void system_deep_sleep(uint32 time_in_us) One thing should be noticed that there’s possibility bricking the Wio if not programed properly. Once this happened, must reflash the firmware for Wio with the esp8266 flash tool or esptool here github.com/igrr/esptool-ck. We’re study the failsafe mechanism…
Because the ULB is still in dev, any suggestion from your digging is appreciated.
Oh by the way, your project sounds really fancy! especially the solar charging part 
Because the forum doesn’t have a Like button, I have to do it this way: “LIKE”
Thanks for the info - super - I’ll give it a go…