Update air temperature continuously on Weave Hvac host device - google-weave

I have an Hvac host device (see interface below) connected to Weave using Libiota and I'm having some trouble understanding how to update the current ambient air temperature (measured on the device). I can measure it but I don't know how to update the state continuously so my Weave client displays the latest ambient air temperature.
I don't fully understand this implementation note in the documentation:
"Changes to the measured ambient temperature should be reported to the
cloud service when the temperature value changes by the minimum level
of granularity for the device UI, for example in 0.5 or 1 degree. If
the device does not support event-based reporting and utilizes
polling, the device should confirm a temperature value change of 0.5
or 1 degree, whichever is the UI's level of granularity, and update
the cloud service at most once every 90 seconds."
I'm able to update the current air temperature at device initialization (inside hvac_controller.c) and upon set temperature setting (i.e. when the heating temperature changes -inside hvac_controller_traits.c-). I'm using this to update the ambient air temperature: IOTA_MAP_SET(ambient_air_temperature_state, degrees_celsius, myvalue);
Interface:
// Create the example hvac controller interface.
g_hvac_controller = GoogHvacControllerDevice_create(
GoogHvacControllerDevice_WITH_AMBIENT_AIR_TEMPERATURE |
GoogHvacControllerDevice_WITH_AMBIENT_AIR_HUMIDITY |
GoogHvacControllerDevice_WITH_DISPLAY_UNITS |
GoogHvacControllerDevice_WITH_HEAT_SUBSYSTEM |
GoogHvacControllerDevice_WITH_HEAT_SETTING);

After understanding that the device (and not Weave) should poll and update the air temperature state with IOTA_MAP_SET(), I tackled this with a pthread.
Here's my main.c
...
#include <pthread.h>
// Function ran by background thread
void *update_air_temperature() {
GoogTempSensor* ambient_air_temperature =
GoogHvacControllerDevice_get_ambient_air_temperature(g_hvac_controller);
GoogTempSensor_State* ambient_air_temperature_state =
GoogTempSensor_get_state(ambient_air_temperature);
while(1) {
// Update air temperature state every 90 seconds
// Read air temperature from sensor
// Code to read sensor and assign value to air_temperature
float air_temperature;
...
// Update air temperature state
IOTA_MAP_SET(ambient_air_temperature_state, degrees_celsius, air_temperature);
sleep(90);
}
return NULL;
}
static IotaDaemon* create_hvac_controller_daemon_(void) {
IOTA_LOG_INFO("Inside create_hvac_controller_daemon_");
// Create the example hvac controller interface.
g_hvac_controller = GoogHvacControllerDevice_create(
GoogHvacControllerDevice_WITH_AMBIENT_AIR_TEMPERATURE |
GoogHvacControllerDevice_WITH_AMBIENT_AIR_HUMIDITY |
GoogHvacControllerDevice_WITH_DISPLAY_UNITS |
GoogHvacControllerDevice_WITH_HEAT_SUBSYSTEM |
GoogHvacControllerDevice_WITH_HEAT_SETTING);
IotaDevice* iota_device = iota_device_create_from_interface(
(IotaInterface*)g_hvac_controller, (IotaModelManifestId){"AHXXX"});
if (iota_device == NULL) {
IOTA_LOG_ERROR("Device create from interface failed");
GoogHvacControllerDevice_destroy(g_hvac_controller);
return NULL;
}
g_iota_daemon = host_framework_create_daemon("hvac_controller", iota_device);
// Set default state of traits on the hvac_controller.
example_hvac_controller_configure(g_hvac_controller, g_iota_daemon,
"Heating");
// Background thread to update air temperature
pthread_t thread1;
pthread_create(&thread1, NULL, update_air_temperature, NULL);
return g_iota_daemon;
}
int main(int argc, char** argv) {
HostIotaFrameworkConfig config = (HostIotaFrameworkConfig){
.base =
(IotaFrameworkConfig){
.cli_commands = NULL,
.num_commands = 0,
.builder = create_hvac_controller_daemon_,
},
.argc = argc,
.argv = argv,
.user_data = NULL,
.name = "hvac controller",
};
return host_framework_main(&config);
}
Don't forget to add -lpthread to the makefile:
...
EXTRA_LIBS=-lpthread
EXAMPLE_OUT_DIR := $(ARCH_OUT_DIR)/examples/$(EXAMPLE)
...
$(EXAMPLE_BIN): $(LIBIOTA_STATIC_LIB) $(PLATFORM_STATIC_LIB) \
$(EXAMPLES_COMMON_LIB) $(HOST_DEVFW_LIB) \
$(EXAMPLE_OBJECTS) | $(EXAMPLE_OUT_DIR)
$(CC) -Wl,--start-group $^ -Wl,--end-group -o $# $(LDLIBS) $(PLATFORM_LDLIBS) $(EXTRA_LIBS)
...
Keep in mind that you should only report the new air temperature when it changes, and at a max frequency of 90 seconds. From the documentation:
Changes to the measured ambient temperature should be reported to the
cloud service when the temperature value changes by the minimum level
of granularity for the device UI, for example in 0.5 or 1 degree. If
the device does not support event-based reporting and utilizes
polling, the device should confirm a temperature value change of 0.5
or 1 degree, whichever is the UI's level of granularity, and update
the cloud service at most once every 90 seconds.

Changing libiota-owned state from outside of the daemon thread could cause trouble. You should use host_iota_daemon_queue_application_job to post a callback to be invoked on the libiota daemon thread, rather than call IOTA_MAP_SET directly from your application thread.

Related

OnboardSDK: mission management and HomePoint initialization

I am having Matrice 210 and use OSDK for uploading mission. But the OSDK will not allow uploading if the HomePoint of the aircraft was not initialized.
I got error "WAYPOINT_MISSION_POINTS_TOO_FAR" if turning on the drone only, and I have to turn on RC and connect DJI GO application for the HomePoint being created.
If I understand correctly, the mission manager only accept mission when the drone has strong GPS signal, but the document do not say anything about the HomePoint initializing.
I try to find in the SDK a function to tell the drone get it current GPS as HomePoint, but there is no such thing available in the code. Do I miss something?
Update:
Here is how I setup the mission manager:
void setWaypointInitDefaults(WayPointInitSettings* fdata)
{
fdata->maxVelocity = 10;
fdata->idleVelocity = 5;
fdata->finishAction = 0;
fdata->executiveTimes = 1;
fdata->yawMode = 0;
fdata->traceMode = 0;
fdata->RCLostAction = 1;
fdata->gimbalPitch = 0;
fdata->latitude = 0;
fdata->longitude = 0;
fdata->altitude = 0;
}
...
bool InitWaypointMission(Vehicle* vehicle, int numberWaypoints, double maxSpeed, double turnSpeed, bool usePointsHeading)
{
WayPointInitSettings fdata;
setWaypointInitDefaults(&fdata);
fdata.indexNumber = numberWaypoints;
fdata.maxVelocity = maxSpeed;
fdata.idleVelocity = turnSpeed;
if ( usePointsHeading )
fdata.yawMode = 3;
ACK::ErrorCode initAck = vehicle->missionManager->init(DJI_MISSION_TYPE::WAYPOINT, responseTimeout, &fdata);
if (ACK::getError(initAck))
{
ACK::getErrorCodeMessage(initAck, __func__);
return false;
}
vehicle->missionManager->printInfo();
return true;
}
On DJI drones, the Homepoint is automatically acquired when the drone has visibility of enough GPS satellites. A method that can tell the drone to get its' current position as homepoint will not be useful - if the drone can indeed get a good fix on its' current location in GPS co-ordinates, it has already set it as a homepoint, or will do so in the next few seconds.
There may be many reasons why you are getting the WAYPOINT_MISSION_POINTS_TOO_FAR error, but you will need to provide more context to help us narrow it down. Some things that are useful to report:
After powering on the drone, how long are you letting it sit in clear
skies before trying to upload the mission?
When you initialize your waypoint mission through the MissionManager, have you made sure to set the RCLostAction to Keep Going?
Is the behavior reproducible in simulation?

winapi bypass Windows high contrast limit fps

I'm using Windows 10 Professional high contrast mode for working at night.
I'm working in a Cocos2d-x 3.15 project, which using these following Win32 API:
UINT TARGET_RESOLUTION = 1; // 1 millisecond target resolution
TIMECAPS tc;
UINT wTimerRes = 0;
if (TIMERR_NOERROR == timeGetDevCaps(&tc, sizeof(TIMECAPS)))
{
wTimerRes = std::min(std::max(tc.wPeriodMin, TARGET_RESOLUTION), tc.wPeriodMax);
timeBeginPeriod(wTimerRes);// request minimum time resolution to 1
}
It's not truly these following code, just an example.
while(true)//main loop
{
mainGameLoop();
int workedTime= calculateWorkedTime();// miliseconds
if(workedTime < 1000/60)// target 60fps
{
int remainingTime = 1000/60 - workedTime;
Sleep(remainingTime);
}
}
In normal state, my game will run at 60fps on Windows (nearly 60fps). But in high contrast, the game is limited to 30fps (feel very annoying when testing games).
I played many games that have 60fps fine. Can I do some trick in my project to bypass the 30fps limit (using Win32 API)?
p/s: This project uses OpenGL.

PIC 16F628A clears its registers?

System is basic but I have terrible problem and I can not solve it pls help me. When my system works PIC keep running but clear the registers 4-5 times in a day.
How system should work:
-I have a PIC, pneumatic cylinder and 3 sensor(works with 24V DC).
-Main sensor take the signal from another system.
-When a signal came from main sensor, if the cyclinder is backward, cylinder should go to forward until forward sensor see it and if the cylinder is forward, cyclinder should come to backward until backward sensor see it.
Program:
#include <16F628A.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or
B5(PIC18) used for I/O
#use delay(crystal=4000000)
#use fast_io(a)
#use fast_io(b)
#define goForward PIN_A0
#define comeBackward PIN_A1
#define main_sensor PIN_B0
#define positionSensorForward PIN_B5
#define positionSensorBackward PIN_B4
int1 pistonPositionedForward=0, pistonPositionedBackward=1;
int1 positionForwardReg=0, positionBackwardReg=0;
int1 pistonForwarding=0, pistonBackwarding=0;
#priority rb,ext
#int_RB NOCLEAR
void B_change()
{
positionForwardReg=input(positionSensorForward);
positionBackwardReg=input(positionSensorBackward);
if(positionForwardReg&&pistonForwarding) //if forwarding and forward sensor see
{
disable_interrupts(INT_RB);
output_low(goForward);
pistonPositionedForward=1;
pistonPositionedBackward=0;
write_eeprom(0,1);
write_eeprom(1,0);
pistonForwarding=0;
pistonBackwarding=0;
clear_interrupt(int_ext);
enable_interrupts(INT_EXT);
}
else if(positionBackwardReg&&pistonBackwarding) //if backwarding and backward sensor see
{
disable_interrupts(INT_RB);
output_low(comeBackward);
pistonPositionedForward=0;
pistonPositionedBackward=1;
write_eeprom(0,0);
write_eeprom(1,1);
pistonForwarding=0;
pistonBackwarding=0;
clear_interrupt(int_ext);
enable_interrupts(INT_EXT);
}
clear_interrupt(int_rb);
}
#int_ext NOCLEAR
void ext_interrupt()
{
disable_interrupts(INT_EXT);
positionForwardReg=input(positionSensorForward);
positionBackwardReg=input(positionSensorBackward);
if(positionForwardReg^positionBackwardReg) //if one of position sensor is see then position according to sensor, else position according to memory
{
pistonPositionedForward=positionForwardReg;
pistonPositionedBackward=positionBackwardReg;
}
if(pistonPositionedForward)
{
pistonBackwarding=1;
pistonForwarding=0;
output_high(comeBackward);
clear_interrupt(int_rb);
enable_interrupts(INT_RB);
}
else if(pistonPositionedBackward)
{
pistonForwarding=1;
pistonBackwarding=0;
output_high(goForward);
clear_interrupt(int_rb);
enable_interrupts(INT_RB);
}
clear_interrupt(int_ext);
}
void main()
{
//to remember last position after power off
pistonPositionedForward=read_eeprom(0);
pistonPositionedBackward==read_eeprom(1);
set_tris_a(0x00);
set_tris_b(0xFF);
output_a(0x00);
delay_ms(1000);
ext_int_edge(L_TO_H);
clear_interrupt(int_ext);
enable_interrupts(INT_EXT);
enable_interrupts(GLOBAL);
while(TRUE)
{
}
}
And my circuit:
CIRCUIT
*j2,j3 connected selonoid valve
*J4,J5,J6 connected 3 sensors 1. pin +24VDC,2. pin GND, 3.pin sensor data
***B1 and B2 connections changed. Now B1 connected to B5,B2 connected to B4
And These are I tried:
-I have 3 PIC all of them do same thing
-I changed 24V power supply
-I cancelled 7805 and 7812 and I connected seperate 5V power supply istead of 7805.
I am debugging via LEDs. Sometimes system stop running just waiting at one of positions. Take main sensor signal but doesnot anything, And pistonPositionedForward and pistonPositionedBackward register values are 0. I cant find problem how can it clear these registers?
You have unconnected pins on RB that are configured as inputs, with no internal pull ups set. Electrical noise may well trigger unwanted interrupts on PORTB, that has been known to happen.
The use of interrupts is making the overall logic a bit hard to follow for such a simple device. Have you tried rewriting the program NOT using interrupts (except maybe for EXT)? It should not take long and I think it may greatly improve the reliability - and maintainability, without impacting performance of the physical system.
I suggest you first configure the unused PORTA and PORTB pins as outputs, and see if the problem goes away. If that fails, a rewrite not using interrupts should take no more than an hour. This would probably make sense since that is probably way shorter than the time you have already spent chasing the issue.
Reading the description, I came up with this solution.
#include <16F628A.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B5(PIC18) used for I/O
#use delay(crystal=4000000)
#use fast_io(a)
#use fast_io(b)
#define FWD_MOVE PIN_A0
#define BACK_MOVE PIN_A1
#define PORTA_RESET (0x00) // outputs=LO, unused pins as outputs
#define PORTA_TRISTATE (0x00)
#define EXT_SENSOR PIN_B0
#define FWD_REST PIN_B5
#define BACK_REST PIN_B4
#define PORTB_RESET (0xCE) // can't use pull ups because of HW logic...
#define PORTB_TRISTATE (0x31)
#define EEPROM_STATUS_ADDR (0x0000)
#define EEPROM_STATUS_FWD (0x01)
#define EEPROM_STATUS_BACK (0x00)
int1 extLast;
int1 extCur;
void main()
{
// setup
output_a(PORTA_RESET):
output_b(PORTB_RESET):
// setting to last known state...
// safety check.
output_low(FWD_MOVE);
output_low(BACK_MOVE);
// This will activate the outputs to make sure we have good
// positioning.
switch(eeprom_read(EEPROM_STATUS_ADDR))
{
default: // EEPROM error... I'll let you decide what to do here.
// either move forward or back.
// this implementation goes back by default.
eeprom_write(EEPROM_STATUS_ADDR, EEPROM_STATUS_BACK);
disable_interrupts(GLOBAL);
// falling through...
case EEPROM_STATUS_BACK:
output_high(BACK_MOVE);
break;
case EEPROM_STATUS_FWD:
output_high(FWD_MOVE);
break;
}
// activate outputs... watch your fingers!
set_tris_a(PORTA_TRISTATE);
set_tris_b(PORTB_TRISTATE);
extLast = input(EXT_SENSOR);
for (;;)
{
// read external sensor, take action.
extCur = input(EXT_SENSOR);
if (extCur && !extlast)
{
// safety check.
output_low(FWD_MOVE);
output_low(BACK_MOVE);
// control logic
switch(eeprom_read(EEPROM_STATUS_ADDR))
{
default: // should never happen.
// falling through...
case EEPROM_STATUS_BACK:
output_high(FWD_MOVE);
eeprom_write(EEPROM_STATUS_ADDR, EEPROM_STATUS_FWD);
disable_interrupts(GLOBAL);
break;
case EEPROM_STATUS_FWD:
output_high(BACK_MOVE);
eeprom_write(EEPROM_STATUS_ADDR, EEPROM_STATUS_BACK);
disable_interrupts(GLOBAL);
break;
}
}
extLast = extCur;
// mechanical interface:
// read the limit guards and stop movement when done.
if (input(FWD_REST))
{
output_low(FWD_MOVE);
}
if (input(BACK_REST))
{
output_low(BACK_MOVE);
}
}
}
Of course, I could not check the above code on-site :).
After reviewing the schematics, I must also advise to add 1N4001 diodes in parallel of the 2 output MOSFETS to give them better protection against reverse voltage spikes. MOSFET built-in diodes are not very sturdy. 1N4148 or 1N914 would work there as well.
The 16F628 has very limited stack space. It looks like you are experiencing stack overflow during the call to write_eeprom. Calling write_eeprom from an interrupt may not be such a good idea after all.
There was a bug in older CCS compilers, related to the use of write_eeprom. It seems write_eeprom is enabling interrupts during the call. I've added calls to disable interrupts after the writes. I don't know if that bug was fixed, since I never use CCS.
[EDIT] after checking your HW. I realized you cannot use internal pull-ups because the HW logic is positive-going. The pull-ups in the PIC are meant to work with NPN transistors in the open collector configuration (emitter to ground). I changed the code accordingly.
The way you write to EEPROM is not good. eeprom writes take time, and the second write is usually taken care of in the eeprom interrupt. The CCS bug that enables the global interrupt and unmask the EEIE in eeprom_write does not help. Unhandled interrupts do generate a reset.

DHT11 is not reading Temperature and Humidity when Arduino is powered on using DC power Supply (12V)

I am facing one problem. I have code which read temperature and humidity using DHT11 sensor. I uploaded following code using Arduino via USB serial, I can read values of temp, humidity. Values are being read as long as Arduino is connected to same laptop via USB.
TEMPERATURE AND HUMIDITY are being read as 0 when I power on Arduino using DC12v, 700MA adapter.
I want to deploy Arduino with DHT sensors connected with it in Greenhouse to read greenhouse environmental condition but when I power on using DC adapter or battery, it is giving "0" output. Note: values are verified when values are transferred via Ethernet to the webserver.
PLEASE HELP TO SOLVE THIS PROBLEM.
DHT dht(DHTPIN, DHTTYPE);
void setup() {
Serial.begin(9600);
Serial.println("DHTxx test!");
dht.begin();
}
void loop() {
// Wait a few seconds between measurements.
delay(2000);
// Reading temperature or humidity takes about 250 milliseconds!
// Sensor readings may also be up to 2 seconds 'old' (its a very slow sensor)
float h = dht.readHumidity();
// Read temperature as Celsius (the default)
float t = dht.readTemperature();
// Read temperature as Fahrenheit (isFahrenheit = true)
float f = dht.readTemperature(true);

How to get multitouch to work in QGraphicsView, Qt 5.0.2 in Windows 8

I am struggling with getting multi-touch to work on a couple of QWidgets that I have added to a QGraphicsView. I have created a subclass of QWidget in which I set up a QGraphicsScene and QGraphicsView. This is my (test) subclass of QWidget:
#include "qttest1.h"
#include <QtWidgets>
#include <QTouchEvent>
qttest1::qttest1(QWidget *parent)
: QWidget(parent)
{
setEnabled(true);
if(!QCoreApplication::testAttribute(Qt::AA_DontCreateNativeWidgetSiblings))
setAttribute(Qt::WA_NativeWindow);
setAttribute(Qt::WA_AcceptTouchEvents);
scene = new QGraphicsScene(this);
scene->setSceneRect(0, 0, 1920, 1080);
graphicsView = new QGraphicsView(scene, this);
graphicsView->setRenderHints(QPainter::Antialiasing);
graphicsView->setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
graphicsView->setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
graphicsView->setAttribute(Qt::WA_AcceptTouchEvents);
graphicsView->viewport()->setAttribute(Qt::WA_AcceptTouchEvents);
QBoxLayout *layout = new QVBoxLayout;
layout->addWidget(graphicsView);
setLayout(layout);
}
qttest1::~qttest1() {}
void qttest1::showGraphics()
{
for(int i = 0; i < 10; i++)
{
Dial *dial = new QDial();
dial->move(i * 120 + 50, 200);
dial->resize(120, 120);
dial->setAttribute(Qt::WA_AcceptTouchEvents);
QGraphicsProxyWidget *proxy = scene->addWidget(dial);
proxy->setAcceptTouchEvents(true);
}
}
This is my main:
int main(int argc, char **argv)
{
QApplication app(argc, argv);
app.setAttribute(Qt::AA_DontCreateNativeWidgetSiblings);
QRect rect = app.desktop()->screenGeometry();
qttest1 test;
test.resize(rect.width(), rect.height());
test.showFullScreen();
test.showGraphics();
return app.exec();
}
I know the code isn't pretty and probably leaking a bit, but the point is to try to get multi-touch to work.
I can see and use every kind of widget I add to the scene, but as soon as I touch a dial it swallows every touch that comes after the first. Which makes the dial jump between several positions. What I want is that every dial (or any type of widget) can be used individually and at the same time. I am using QT 5.0.2, Windows 8 with a monitor that supports up to 10 touches.
The Qt docs state : -
Reimplement QWidget::event() or QAbstractScrollArea::viewportEvent()
for widgets and QGraphicsItem::sceneEvent() for items in a graphics
view to receive touch events.
With that, I believe that you need to handle the QEvent::TouchBegin, QEvent::TouchUpdate and QEvent::TouchEnd events, which I don't see in the code you've posted.
Qt may handle the first touch for you, but it's not going to know what you want to do with the second, third, fourth etc. simultaneous touches. For example, you may want your app to do any of the following with the second touch moving: -
1) Rotate the object that the first item is over
2) Scale the object that the first item is over
3) Select the second item
4) Translate the view
5) etc.
So, you need to handle the consecutive touches to do what you want it to do. Also, you may want to look at Gestures in Qt.

Resources