websocket doesn't work/connect. about picoreflow HOT 14 OPEN

That's a pity!

The "Error 1: status websocket not available - which is all red and ominous" is indeed a serious problem, because the webclient uses this websocket in the background to talk to the picoreflowd running on the Pi. Could you please paste a complete log from the beginning to get a better idea if the sensor was found and what might be going on there. I don't have a B+ available to test, maybe there is some nasty internal pin remapping happening.

IIRC you don't have to use the specific SPI pins though, you should be able to use any digital in/out pin, did you test a different hardware interface configuration?

from picoreflow.

Here's the whole shebang:

root@raspberrypi:~/picoReflow# python picoreflowd.py
2014-12-17 07:56:05,069 INFO picoreflowd: Starting picoreflowd
2014-12-17 07:56:05,156 INFO picoreflowd: listening on 0.0.0.0:8080
2014-12-17 07:56:31,608 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET / HTTP/1.1" 303 178 0.008493
2014-12-17 07:56:31,722 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/index.html HTTP/1.1" 304 66 0.106182
2014-12-17 07:56:31,810 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/js/jquery.event.drag-2.2.js HTTP/1.1" 304 66 0.008362
2014-12-17 07:56:31,826 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/css/bootstrap-theme.min.css HTTP/1.1" 304 66 0.006915
2014-12-17 07:56:31,839 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/css/bootstrap-modal.css HTTP/1.1" 304 66 0.005786
2014-12-17 07:56:31,853 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/css/select2.css HTTP/1.1" 304 66 0.005555
2014-12-17 07:56:31,867 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/css/picoreflow.css HTTP/1.1" 304 66 0.005774
2014-12-17 07:56:31,881 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/js/bootstrap.min.js HTTP/1.1" 304 66 0.006226
2014-12-17 07:56:31,895 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/js/jquery.bootstrap-growl.min.js HTTP/1.1" 304 66 0.005627
2014-12-17 07:56:31,908 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/js/select2.min.js HTTP/1.1" 304 66 0.005786
2014-12-17 07:56:31,922 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/js/picoreflow.js HTTP/1.1" 304 66 0.005655
2014-12-17 07:56:31,936 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/js/jquery.flot.js HTTP/1.1" 304 66 0.005611
2014-12-17 07:56:31,951 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/js/jquery.flot.resize.js HTTP/1.1" 304 66 0.005559
2014-12-17 07:56:31,965 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/js/jquery.flot.draggable.js HTTP/1.1" 304 66 0.005519
2014-12-17 07:56:31,980 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/css/bootstrap.min.css HTTP/1.1" 304 66 0.005865
2014-12-17 07:56:31,995 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:31] "GET /picoreflow/assets/js/jquery-1.10.2.min.js HTTP/1.1" 304 66 0.005506
{'profile': None, 'type': 'backlog', 'log': []}
{"profile": null, "type": "backlog", "log": []}
2014-12-17 07:56:32,053 INFO picoreflowd: websocket (status) opened
2014-12-17 07:56:32,069 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:32] "GET /picoreflow/assets/fonts/tables.woff HTTP/1.1" 304 66 0.006890
2014-12-17 07:56:32,084 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:32] "GET /picoreflow/assets/fonts/glyphicons-halflings-regular.woff HTTP/1.1" 304 66 0.005489
2014-12-17 07:56:32,099 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:32] "GET /picoreflow/assets/fonts/digital-7-webfont.woff HTTP/1.1" 304 66 0.006563
2014-12-17 07:56:32,116 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:32] "GET /picoreflow/assets/images/panel_bg.png HTTP/1.1" 304 66 0.006880
2014-12-17 07:56:32,130 INFO picoreflowd: websocket (control) opened
2014-12-17 07:56:32,147 INFO geventwebsocket.handler: 10.0.10.11 - - [2014-12-17 07:56:32] "GET /picoreflow/assets/css/select2.png HTTP/1.1" 304 66 0.006108
2014-12-17 07:56:32,160 INFO picoreflowd: websocket (storage) opened

at which point I had to cancel the program/server.

A possibly related issue is that the moment I run the picoreflowd.py program the oven turns on immediately and stays on. I haven't used the same pinouts you did because I was designing my own software and using the SPI port with the bcm2835 library. So I have config.py as follows:

Outputs

gpio_heat = 18 # Switches zero-cross solid-state-relay
gpio_cool = 21 # Regulates PWM for 12V DC Blower
gpio_air = 20 # Switches 0-phase det. solid-state-relay

Inputs

gpio_door = 16

MAX31855 K-Type Thermocouple I2C

gpio_sensor_cs = 8
gpio_sensor_clock = 11
gpio_sensor_data = 9

I think I have the numbering scheme correct. the heat relay is attached to a Raspberry Pi B+ J8_12 pin (GPIO18). I used this pin for the relay because it is also the PWM pin and that makes for some smooth automatic "dimming" of the heating element in my original system.

CS is connected to J8_26 (GPIO08) as that is the CS0 pin for the SPI (which python is STUPID for not supporting native SPI communication, yet by the way). Similarly clock and data are connected to J8_23 and J8_21 respectively which are GPIO11 and GPIO09 respectively.

So... Why is the websocket failing?
Why is the oven turning on immediately and staying on (though now I know my oven reaches 380 degrees celcius)
Why am I not getting any reasonable temperature reads?

from picoreflow.

Wow, that's really serious. Usually it should ONLY turn on, when a job is actually selected and started. Just (re)starting picoreflowd should never activate actors connected to the system! The log doesn't give much clues either, just that it actually seems to be able to start the status, control and storage websockets, indicating no python/lib related problems (RPi.GPIO etc.).

Unfortunately the current development state of picoreflowd is just a mere PoC Demonstrator hack (and quite old at that) and hasn't evolved enough to offer features to debug it more comfortably, I'll also put that into the roadmap https://apollo.open-resource.org/pad/picoPID. You're welcome to review and add the viewpoints of your specific reality/use-cases as well.

I still have no more clue why it might be failing on your end, it seems like there is more than one problem:

• Web-Client to status websocket communication fails (Which browser?)
• No temperature readings from MAX31855
• picoreflowd turns heat on immediately after start

This could all be single instances of problems or a chained reaction to the failure of one instance.
I'm sorry, at this point, without further details and the possibility to replicate your setup (or access to it) it is like trying to read the future from a glass sphere.

If you know your ways around python you could hack some more debug code into picoreflowd to see what's really going on. I'm not sure (too long ago) if our particular setup had the outputs inverted for some weird reason (which would be bad but might explain the immediate turn on :)). I would try to isolate it into several buckets and start with the temperature board, hack around to check if you can get a valid reading from the board with just the basic example: https://github.com/Tuckie/max31855.

Since in the last couple of weeks more and more people seem to have stumbled over picoreflowd and already experiment with the stack to build all kinds of PID temperature control robots, it seems worthwhile to me to re-schedule a portion of the upcoming sprint into moving picoReflow to picoPID, so that we have something that will be more of a "runs-out-of-the-box" package for any kind of temperature control, where we don't have to hack around in order to get it nicely suited into whatever we want to accomplish with it.

If it would be possible for you to give me ssh access to the pi running it and making sure the actors are not connected to anything more than a LED (fire risk) I could have a more in depth look to find out what's really going on there.

Again, I'm sorry I can't offer any other quick solution because first I would need to know what the real problem is. Hopefully, with a quick move picoPID we can evolve the stack enough to deploy in a more user-friendly fashion, anywhere, easily. If you can, you're welcome to help, if not, I just have to beg your patience until we come up and release something more "state-of-our-current-art".

from picoreflow.

After reviewing pr/7, I found something that bugged me before but I didn't realize it: The log output shows no interaction with the thermocouple adapter at all. No failure and no init either. Could you please pull the current master, create a new config according to the example with your pin configuration and submit the log?

from picoreflow.

I also had my SSRs turning on as soon as the python program was run. I needed to swap the controls to on=HIGH and off=LOW. The code has on=LOW and off=HIGH as written. That doesn't help your websocket issue though.

from picoreflow.

After running fine for me many times, I am now having the websocket stall on (or after) loading the picoreflow.css (it is the last entry in the log). Pulling up the webpage, everything loads but the profiles. So I can not run the system. Tried it on multiple computers/browsers, and they are all the same. Multiple restarts of the Pi to no avail.

Last night I ran a 6 hour run. The websocket stopped updating the website after ~4 hours, as expected from previous runs. The program ran to completion on the python side, but I was never able to get the webpage to completely load again after that.

Any ideas?
I'll try doing a clean install and see if that makes a difference.

from picoreflow.

Yes, the output mapping needs to be defined by the user as of now, since some systems need a high to have output state = low, it all depends on the hardware connected to it and as such is currently up to the person implementing it to figure out correctly.

It's most likely the contents stored in the leveldb, so you could basically just checkout the contents of of the the leveldb storage folder again to get a clean slate as opposed to doing everything from scratch. However, have you had a look into the javascript console in the browser to see if there are any obvious error messages indicating what specifically causes the bug? My guess is the flot/jquery combo, that's why we've rejected it for PiGI and went with dygraph. Flot was just the first candidate that was easy enough to implement and it definitely has problems when the amount of datapoints to draw exceeds a certain limit. If you have a mic/webcam, you're welcome to join us on https://apollo.open-resource.org/flight-control/conference/

from picoreflow.

I didn't notice any errors. There was a warning about not using a "generic" version of a specific command. But it wasn't an error. It just seemed to be stalled at that point. It kept taking new websocket requests, but then stalled again (not always at the same point though).

from picoreflow.

ACH!!! I had a stupid syntax error from when I was messing with the time unit display. Its running again! YAY!

The warning I talked about before frome Chrome is:
'webkitRequestAnimationFrame' is vendor-specific. Please use the standard 'requestAnimationFrame' instead.
From:
jquery.flot.resize.js line 23

From Firefox I get:
Use of getPreventDefault() is deprecated. Use defaultPrevented instead.
From:
jquery-1.10.2.min.js

Could that be causing the issue?

from picoreflow.

Yeah, that has been there all the time, comes from upstream flot. Both are just warnings/deprecation notices, they're not nice but usually didn't mess with operation. But they were also reasons why I wanted to move away from jquery and flot as well :)

from picoreflow.

Sorry for the absence... I downloaded the latest version and things are a bit better but not perfect now.

Better: The max31855 thermocouple is now reading temperature correctly when connected to the SPI pins (I originally designed my electronics to communicate using the natural SPI pins and I used the PWM capable GPIO pin to drive the heating element, I have changed the config.py file to reflect this) So now the temperatures read.

Better: The websocket seems to be working fine now.

Not working still: The oven's on/off state still seems to be reversed. The oven is on when it should be off and vice versa. I read ScottW1's post about "off=HIGH" but I cannot find any such line/position to change this string anywhere in any of the picoReflow files. And I'm skeptical about this existing. But I did find the self_heat method in oven.py and it seems it wants to turn the oven ON when value is true. and the argument sent to GPIO.Output in the true condition is GPIO.LOW which is the opposite of what I need since my SSR is active high. So I swapped the GPIO.HIGH/GPIO.LOW values.

So I think things are working now. Yay!!!

A suggestion... My unit does not have a door switch or fan. I configured those pins in the config.py to unconnected GPIO pins in the raspberry pi but I think it would be nice if the software made these two switches and their features entirely optional.

from picoreflow.

Yes, you are correct. I referred to the GPIO pins being pulled high or low. In the code the syntax is TRUE or FALSE. Sorry for the confusion.

from picoreflow.

I spoke too soon. The "Error 1: Status websocket not available" problem is back but now I have more information. The raspberry pi/picoReflow is connected to my home network via a wifi usb dongle. I have two workstations that use chrome on to attempt to connect to the picoReflow system. One is a wired desktop and one is a wifi laptop.

The wired desktop works fine and the picoReflow works as expected.

The wifi laptop does not work and throws the "Status websocket not available".

Does anyone know why a wifi-wifi attempt would have this probem and a wired-wifi would not?? very strange.

from picoreflow.

Hmm that doesn't sound like a problem in the software itself, more like a problem with the setup. can you do a netstat -patune on the pi and see if the server is listening on 0.0.0.0 or at least the IP of the wifi interface? In our test setup the Pi was also connected via WiFI (as a client to another AP) and we could use both WiFi and Ethernet clients simultaneously without a problem. I'll try to find which WiFi stick we used, as there are some which were causing some trouble with the PI IIRC.

The oven control is done in https://github.com/apollo-ng/picoReflow/blob/master/lib/oven.py

Noted your feedback as it pretty much just ups the "more flexibility with IO" wishlist count :) That will definitely come with the next milestone.

from picoreflow.