Cannot support polling interval plus listen for events

[brianehlert]

My scenario is this: I have a PIR sensor plus a DHT22 temp/humidity sensor.

If I set an interval of 10 seconds - I get perfect output from my DHT sensor. However my PIR state change is never captured. (it is as if it is not there, I never see that any message is sent when the state of the PIR changes).
If I set no interval for the DHT sensor - I get perfect messages from my PIR sensor, and thus a return message to set the pin state of an LED.

What I find is interesting is that I cannot have both working properly at the same time. So I am guessing that if I set an interval, it applies to the entire Arduino / Microblu device. If I don't set an interval and respond to output from the pins, then that too applies to the entire device.

Not positive if this is a Microblu issue or a Meshblu issue for certain.

[chrismatthieu]

It sounds like a Microblu issue but we will check it out...
Copying: @redaphid @royvandewater @iamruinous @kmariano @virgilvox @monteslu @jacobrosenthal

[chrismatthieu]

@brianehlert By chance do you have both sensors connected to the same bank of pins on the Arduino? If so, try moving one of the sensors to another bank of pins.

[brianehlert]

They are both digital. And in the 0-7 group.

I could not figure out how to define an analog pin.

And I was avoiding the 8-14 as that is where the network card sits, so I went for easy.

[chrismatthieu]

It looks like pins 8 & 9 are free to use.

[brianehlert]

moved the DHT to pin 9.
Added a delay to the workflow to read pin 9.
The PIR state on pin 3 was not captured.
Removed the delay, then the PIR state change was captured, but the DHT
value is not correct (1 vs the real 13 digit value).

On Tue, Oct 21, 2014 at 10:17 AM, Chris Matthieu [email protected]
wrote:

It looks like pins 8 & 9 are free to use.

Reply to this email directly or view it on GitHub
#6 (comment).

[brianehlert]

https://gist.github.com/brianehlert/0b9b811047af35bd9ddd

[royvandewater]

We've been looking at the DHT22 spec sheet (https://www.adafruit.com/datasheets/DHT22.pdf), and it looks like it's intended to operate by Arduino sending a digital high, switching that pin to read, and reading in a 40-bit digital value over the span of 5ms. From what we understand of Firmata, it should not be possible to get data from serial sensors.

We recommend using separate analog humidity and temperature sensors, this way, each one would occupy a separate pin and produce a continuous value that Arduino can send up to Meshblu at the configured sampling interval. If you go that route, Meshblu rate limits at 10 messages per second, so with two sensors, you would need to have a samplingInterval > 200ms.

Admittedly, I don't know all that much about reading serial streams from digital sensors, so I may be misunderstanding the problem :-p

[brianehlert]

The issue is not the sensor (though I understand your comments).
The issue is that I have one device (the Arduino) with multiple sensors, and different polling styles / rates for the different sensors.
I have a sensor that needs to fire a message when a change in its state is detected. I have a second sensor that needs to be polled / queried for its value.
And the two combined, in the same workflow (with two different paths) doesn't work.
I am assuming that putting both sensors in the same flow was correct, as having one flow per sensor did not seem to fit the paradigm.

Also, this week my workflow keeps 'getting stuck' - as in stops responding. And I need to resent it. But that is a different issue (I am assuming).

[royvandewater]

From what I understand, the polling style of the DHT sensor shouldn't work at all with how we're using Firmata over Meshblu. The interface requires the port to be in digitalWrite, sent a HIGH signal and then the port to be switched to digitalRead within 5ms. Standard Firmata (the code in the "Standard Firmata" example that ships with Arduino) is supposed to set each pin to either read or write, but not both. I think it may technically be possible to trick it into doing both, since digitalRead is set on per port and digitalWrite is set per pin. I think you may have accomplished this by having multiple Microblu nodes address pins on the same port.

I think each microblu node in the designer sends the entire port configuration, with non-addressed ports set to default. So if I have a node that addresses pin 1, and one that addresses pin 2, I think that whichever of the nodes hits Microblu on the Arduino last overwrites the mode of the other. We saw this with our Grim Reaper, where if we had his jaw on pin 3 and his eyes on pin 5, we could control either his jaw or his eyes after a deploy, but not both, and which one we could control was non-deterministicly set each time we deployed. In our case, we quick-fixed it by putting them on separate ports, but that's not a long term solution (It kinda sucks to limit Arduino to only 3 pins).

I'm going to experiment with it and see if I can duplicate what I just described. If that works, it would be possible to read values from 7 sensors per port (with all 7 pins set to digitalWrite) and the remaining pin set to digitalRead. It still won't address the 40-bit serial read, but it might get a little further.

[royvandewater]

We were able to get the DHT22 to emit some information, but it takes advantage of the delay in between each microblu node's Firmata pinmode transmission. Here's how I got it sending stuff: https://gist.github.com/royvandewater/ddb403eda4052181df53

This one gets data with both the DHT22 sensor, still receives signals from the PIR sensor, and writes to the LED. However, it will only ever read from the DHT22 once, at deploy time.

[brianehlert]

Thanks for the time. While the sensor is an interesting puzzle due to how it works and how to handle such a thing with Microblu. It is really not my issue.
I am going to try with my PIR (watch state), plus a button (watch state), plus an analog photocell (poll on interval) to have a less complex situation.