ARDUINO & BLUE IRIS SERIAL digital i/o DIO

How do I get BI to open the serial port? I am using a port monitor and BI is not sending anything to the port.

My guess is that maybe some other process is using the port, and nothing is getting through, but there's no way to check via BI.

I got it working once but do not know how, and I cannot repeat it. Using arduino's built in serial monitor I can send the bytes manually, so I know the code is correct.
 
Last edited by a moderator:
Thats a really good question. On a second PC I downloaded and installed BI, enabled my desktop web cam and checked Open DIO on COM 11 with GCE protocol. Everything else virginal. Terminal program cannot talk to or hear BI. There doesn't seem to be a way to force a connect to the BI port of choice and it doesn't show up any where. All this under win7-64. Some other people can do it, just not us.
Eric
 
In almost all cases to open a com or serial port a program needs exclusive access to it, so if you already have a terminal program monitoring a com port then Blueiris will then not be bale to access it & vicaversa..

"How do I get BI to open the serial port? I am using a port monitor and BI is not sending anything to the port."
In this case you are trying to monitor the port with both BI and the terminal program
 
That's what I would have thought too; depending on the order I open the monitor and/or BI sometimes I cant open the arduino serial window to send test commands, it will say "com port in use".

However the one and only time I got it working by accident I did have the monitor open and it did read the S00 and S01 commands... So I have no idea!
 
I have a tool that looks at all the PC ports both COM and USB and reports whether used or not and if they have ever been used. So I pick a comport like 28 that has never been claimed and set my BI eval version to that port, save it and shut down the WIN7 PC. Re boot PC, start task manager to see that nothing is running. Start BI and wave at camera to verify motion detection operation. Start terminal program - It doesn't recognize 28 as having anything on it but conect it anyway. Wave at BI cam1 and nothing on terminal, send BI DIO an ASCII 1, no response.
A second thing I tried is using a port bridge program between the terminal and BI. The virtual ports are usually not so finicky about connecting to various devices.

I think that we need a little support to figure this one out. I wish that there was a serial IP connection for the Arduino. IP ports have the further advantage that they can handle multiple simultaneous connections gracefully.
I'm out of ideas, anyone out there with more ideas?
Eric
 
Hello CDS333
We are in the same boat but I am making progress with BI ~ Arduino communication. Things that I have figured out: BI4 only loads its COM port when it boots. You can change it and the number shown is not relevant.............. until after BI is restarted. Knowing this saves a whole bunch of frustration. I connected two USB to COM port adapters to my PC (as close as I can get to real hardware com ports) one set to com 3 and the other to com 4. This allows me to look at connector pins to see what BI is doing when I effect motion on camera. Com3 on BI and com4 on a terminal program. You know that a camera is triggered when you get a red frame around its image. The help says that you send an ASCII 1 with the GCE protocol selected in Digital I/O and you will trigger camera 1 if you have "Trigger with DIO input bits" checked and a 1 in the box. All well and good this works as it should many times but not all the time, not every time. Also important you must follow your 1, 2, 4, or 8 digit with a carrige return (CR) or nothing will ever happen. When you send your ASCII string to BI it helps to have space characters ahead (maybe 30) of your 124or8 and spaces following but before the CR.

There doesn't seem to be a pattern, send 3 or 4 characters and BI triggers every time, then it will skip responding for a few more tries and then it will work again. It acts like if BI is busy on other tasks the Digital I/O is just not serviced. In my application I can't afford to miss to many ones. There appears to be a few forum members out there successfully using the Digital I/O, do you have any issues, maybe this is a bug introduced in the latest releases.

Whats going on here?
Eric
 
I got it working. It seems restarting the computer works all of the time so far, and then starting BI before the port monitor program. I think the main problem I was having was that with the above code it was only sending 2 bits, so the IF statement was not triggering. I then chenged it to read all bits and display them on an LCD connected to the arduino. I had started out with an old version of BI that didn't have the option to go above 8 on the output, but have since upgraded to the latest version that goes up to 255

If I want to program the arduino I can program it, and then disconnect and reconnect it in devmgmt.msc and restart BI and it seems to be recognized every time so far. When I first posted here I had been trying to do it without an initial restart of my computer, which seemed to be necessary to get it going the first time.

For those of you who dont know, the output is in the form of SX1 for ON and SX0 for OFF with 'X' being the exponent value in the 2^X row representation of binary. Theoretically the minimum amount of data that can be sent is representing a 1, 2, 4, 8, 16, 32, 64, or 128 value, and it is 3 bytes. Anything else is the combination of the aforementioned; for example, the number 96 would be S51S61, displayed as the decimal equivalent of the bytes S + 5 + 1, etc... So my arduino displays 83 53 49 83 54 49, but the actual value sent is likely HEX, or 53 35 31 53 36 31, arduino just defaults to dec as opposed to hex

But for some reason yesterday I was getting 2 bit outputs, but now I cannot replicate them. (That does explain why it didn't trigger the original IF statement, which requires an input greater than 2)

I haven't messed with input at all, that is my next task. I will let you know how it goes. (I also ordered an ethernet shield, which I hope to integrate with some additional sensors to control via WAN)

BTW eltima serial port monitor does not work for some reason; it constantly gives a "sniff driver" error on startup. I found another one called "Free Device Monitoring Studio" which seems to have no major limitations on the free version, and offers multiple ways of monitoring a serial port for data.

edit: two bit outputs were from the other mode, not GCE
 
Last edited by a moderator:
BTW does anyone know what the Camera DIO thing does or how to get it to work? It doesn't seem to be in the help file.
 
I've put some more time into figuring out whats with the digital I/O in BI. I'm pretty sure that a bug has been introduced. Here's how it is working for me. Latest BI version, Win7, USB to serial adapters on coms 3 & 4, Stripped down BI on com3, Realterm terminal program on com4. BI configuration is as basic as is possible with only one USB camera and no recording.

Start BI then send it a character (BI is setup expecting a 1 to trigger but it doesn't matter) and an alert will be triggered. RED frame and audio alert tones will be output. Send it a second 1 or third or n ones and nothing will happen. Shut down BI and send it a 1 after it restarts and it will trigger but only once.

FWIW when ever the trigger now box (on Motion/Trigger tab) is clicked BI alerts, always works.

It would be useful if cds333 repeated my experiment for confirmation. I think that we need some BI support.
Eric
 
First thing I found out- apparently BI triggers upon receiving the "S01" and stays triggered until I send an "S00". It will literally stay triggered for hours if it only gets the "on". After sending the "off" it takes about 10 seconds to end the triggering, however the "on" trigger happens instantly.

Secondly, make sure if youre using the arduino pins with buttons or whatever to trigger the sending of the serial data, that you use them in pullup mode, because if you use them in conventional mode they will float and mess everything up.

Here is my code thus far, let me know if this helps at all:


#include <LiquidCrystal.h>

LiquidCrystal lcd(12, 11, 5, 4, 3, 2);
int Byte1;
int Byte2;
int Byte3;
int Byte4;
int Byte5;
int Byte6;
int Byte7;
int Byte8;

void setup() {
Serial.begin(9600);
pinMode(8, INPUT_PULLUP);
pinMode(9, INPUT_PULLUP);
pinMode(13, OUTPUT);
digitalWrite(13, LOW);

lcd.begin(16, 2);
lcd.print("Waiting...");
}

void loop() {

int val = digitalRead(8);
int val2 = digitalRead(9);

lcd.setCursor(13,0);
lcd.print("8:");
lcd.setCursor(15,0);
lcd.print(val);
lcd.setCursor(13,1);
lcd.print("9:");
lcd.setCursor(15,1);
lcd.print(val2);

if(val == 0){
Serial.write('S');
Serial.write('0');
Serial.write('1');
digitalWrite(13, HIGH);
delay(2500);
}
if(val2 == 0){
Serial.write('S');
Serial.write('0');
Serial.write('0');
digitalWrite(13, HIGH);
delay(2500);
}
digitalWrite(13, LOW);

if (Serial.available() > 0) {

lcd.clear();
lcd.print(Serial.available());
delay(2000);
Byte1 = Serial.read();
Byte2 = Serial.read();
Byte3 = Serial.read();
Byte4 = Serial.read();
Byte5 = Serial.read();
Byte6 = Serial.read();
Byte7 = Serial.read();
Byte8 = Serial.read();

lcd.setCursor(0,0);
lcd.print(Byte1, HEX);
lcd.setCursor(3,0);
lcd.print(Byte2, HEX);
lcd.setCursor(6,0);
lcd.print(Byte3, HEX);
lcd.setCursor(9,0);
lcd.print(Byte4, HEX);
lcd.setCursor(0,1);
lcd.print(Byte5, HEX);
lcd.setCursor(3,1);
lcd.print(Byte6, HEX);
lcd.setCursor(6,1);
lcd.print(Byte7, HEX);
lcd.setCursor(9,1);
lcd.print(Byte8, HEX);


delay(2500);
exit;

}
}
 
Ok it appears that regarding inputs it only has 4 possible ones: 1,2,4 and 8. You can set the BI input value to anything you want (between 1 and 15) but your actual input is OR'ed with the binary value set in BI.

So if I set my arduino to send a '4', then any binary value with 4 in it will trigger the camera (so 4,5,6,7,12,13,14,15). Same thing if I set the BI value to '1', then a 4 will not trigger it, but a 1,3,5,7,9,11,13, or 15 would.

Sending a '0' ends the triggering, and seems to be mandatory, but still with a delay.


Some other things I've noticed:

-Input seems to abandon the whole "SXX" convention here, you simply send decimal values from the arduino.

-Setting a value in BI larger than 15 will result in a constant trigger.

-Changing the value in BI without restarting will sometimes use the last value instead of the new one.
 
Last edited by a moderator:
  • Like
Reactions: eeeeees
Hello cds333

You get a gold star for figuring out BI Digital I/O behavior. I verified your findings using a terminal as input. Explains why some of the Arduino sketches put out a slow stream of 0 just to keep BI cleaned out.
Thanks again and keep up the good work.
Eric
 
I should have used the terminal too, would have saved some time lol. Ill probly start doing that.

Do you know why it seems to take 10 seconds or so to register an "end trigger" event? Does that happen to you too?
 
I should have used the terminal too, would have saved some time lol. Ill probly start doing that.

Do you know why it seems to take 10 seconds or so to register an "end trigger" event? Does that happen to you too?
If your break time in the motion tab is set to 10, that might explain it.
 
Is there a step by step guide on how to achive Arduino/Blue Iris Digital DIO?
My end goal is to open and close the Garage door with the Blue Iris App "Remote Control" DIO output that controls an Arduino Relay.
 
Hi Manyakus.

When I wrote the code originally I used a serial port sniffer software to see what bits were sent corresponding to each I/O trigger on BI, these bits seemed to change with every BI version.

I then coded the arduino to activate the IO's on the Arduino accordingly.
I then used a trigger circuit with a transistor to drive a relay.

This being said, it is a lot of work and really outdated. As a result we now use the MQTT function in BI to control switches.
You can download firmware for a Sonoff Basic from this website wwwDOTkldtechnologiesDOTcoDOTza , flash it to the Sonoff , use the Mobile App to provision the Sonoff and use the MQ control commands from BI to control the relay.
Just sever the power supply feeds to the relay on the Sonoff board and then use it as a normal Open, Close relay for your garage door using a trigger or pulse command via MQTT.
 
Hi Kevern,

Thank you for the response.
So if I understand correctly, the new more stable method is to buy any Sonoff device and flash it with the Firmware "Sonoff Basic" from the website you have provided?
Then control the Sonoff from Blue Iris over Wifi?