Are there any plans to deploy to RubyGems?

http://community.particle.io/t/pi-ssh-no-longer-responds-after-installing-setup-of-agent/27691

I suspect the IO pin initialization of having this unexpected side effect.

Hello.
Ive got a raspberry pi running the particle agent, and it works really fantastic, Thanks guys!
Im just having one issue. the device wont recieve commands from the api when its connected via 3G.. we're trying to build a system that will rely on 3G connectivity, as it will be away from wifi/ethernet. im not sure if its something that the isp is blocking or what we can do.
I wondered if it is perhaps because (being a mobile connection) it doesnt have a public IP address - most if not all mobile networks are like that, and presumably, this works on the electron, so im not sure what the go is.
Im testing with a Raspberry pi3, a huawei usb 3g modem, and Vodafone NZ sim card (in NZ) the device can browse the web fine, and send https post commands to my api, it just cant recieve commands from the particle api.
As a side note, i have also tried piping it down an always on vpn connection, but this didnt work for me either.

i posted this to Particle support, and they suggested posting here.
Any Pointers?

Thanks

Raspberry Pi Particle-agent 0.2.4 (current)
Tests done using Siglent Digital scope.
I have found on my Raspi 3 B+ that you can use the SPI port within your particle-agent program, but the Particle SPI documentation has a number of errors, and it won't work if you follow the docs as written.

1. You must use either spi.begin(CE0) [which uses CE0/GPIO8 as -CS] or spi1.begin(CE1) [which uses CE1/GPIO7 as -CS] If you use SPI.begin() [as shown in docs] , the compiler throws no errors, the firmware flashes successfully (according to status line) , but program doesn't work. More seriously, after that, if you then try to download corrected/different firmware, or even Tinker, from the online IDE, the firmware download process will indicate success- but whatever code is running on the agent stays intact.The way you can tell that firmware has not been successfully flashed, is that you will NOT see the Raspi go offline momentarily, in the status bar at the bottom right of the Build screen, as you will when firmware flashes OK.
   The only way I could overcome this was to unclaim the device from the Particle console, then run particle-agent setup from Raspi command line.The particle-agent setup alone won't succeed, unless you first unclaim the device.

2. The statement in the docs that your code must toggle the -CS line associated with the SPI port, by using digitalWrite(CE0,LOW), digitalWrite(CE0,HIGH) is FALSE. The SPI.transfer() function does it automatically for CE0, and SPI1.transfer() does it for CE1. Note- this functionality is odd- you do need to use the digitalWrite() commands for normal Arduino code, and I suspect you need to do it if you are using Particle photon,electron, etc.

3. The docs say the default SPI clock speed on the Raspi is 4 MHZ. This is correct. However, the SPI.setClockSpeed() doesn't work, either in the value,scale method (12,MHZ) or the direct method (12000000). The SPI.setClockDivider does work, but only slows the clock way down from 4 MHz. I measured 135 Khz on SPI_CLOCK_DIV4 and 4 Khz on SPI_CLOCK_DIV16. I know the SPI speed can certainly be set much higher than 4 MHz from other languages, such as Python.

4. SPI.setBitOrder function doesn't change it from MSB first (default) to LSB first, if you give it the LSBFIRST parameter. It also put the Raspi in the state in which no further firmware flashes work (like 1 above).

I have a Pi Zero W in the beta program, and currently using 0.51 pi.13.

I have an issue with the String class toFloat() function. It always seems to return 0. I can use the toInt() function on the same string and it works (obviously with truncation).

As a work around I tried to use the C++ functions atof() and strtok(), but these didn't work either.

I then ran the same code on a Photon P1 board and it worked as expected.

However, on the Pi I have got the parseFloat() function in the Stream class to work correctly.

Essentially I was doing this:

String digits = "123.45";
float fnumber = digits.toFloat(); // returns 0
int inumber = digits.toInt(); // returns 123

I can then print fnumber into a string format and the answer is always 0, or casting it to a double to look at it via a particle.variable always produces 0.0.

My Particle-Pi has been failing, during my digging I found a 1.2Gb log file.

See: http://community.particle.io/t/massive-log-file/30143

Currently the firmware shutdowns when it can't reach the Particle Cloud at boot or when the internet drops. However the agent can't distinguish between a firmware crash because of a bad pointer and a crash because of DNS failure so it replaces good firmware by Tinker.

I have been able to successfully flash the Pi using particle's web IDE several times. I'm now getting "Request Timed Out" messages from the IDE.

I've confirmed on the Pi that the particle agent is running and I've tried using systemd to restart the particle-agent as well.

Checked /var/log/particle-agent.log and did not see any errror messages.

I've been playing around with the particle-agent on a Rasberry Pi Zero (v1.3) and have encountered an issue where the particle install fails during the "claiming device" stage and subsequently stops the rPi from connecting to any network.

Setup is as follows:

• Rasberry Pi Zero (v1.3) running Raspbian Stretch (fully updated)
• RedBear IoT pHat (v1.0) with updated EEPROM

After running the setup it will no longer connect to any wifi network. When tested with a freshly installed SD (not running particle-agent) everything connects fine again.

When I connect an external WIFI dongle I am able to complete setup and register the device but as soon as I reboot with the pHat I hit the same problem.

I believe this might be related to #2 as the IoT pHat is connected via the GPIO pins.

https://community.particle.io/t/error-500-when-trying-to-flash-raspberry-pi-3/27537

Writing to Serial eventually blocks the entire process. particle-agent stop doesn't even work.

Root cause:
The standard output of the firmware process is redirected to a pipe by the agent. The pipe is non-blocking, but at some point the kernel must decide there is too much stuff in there and it blocks the firmware process to prevent it from writing any more data.

Steps to reproduce:

• Flash an app that calls Serial.println("stuff"); in a tight loop and publishes once a second.
• After a short while the firmware.bin process will freeze inside the call to Serial.println
• This happens even when monitoring the output with particle-agent serial.

App to reproduce:

SYSTEM_LOOP_DELAY(0);

void loop() {
    static int counter = 0;
    Serial.printlnf("%d", counter++);
    
    static long t = 0;
    if (millis() - t >= 1000) {
        Particle.publish(String::format("rpi/%d", counter));
    }
}