websocket doesn't work/connect. #6
Comments
|
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? |
|
Here's the whole shebang: root@raspberrypi:~/picoReflow# python picoreflowd.py 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: Outputsgpio_heat = 18 # Switches zero-cross solid-state-relay Inputsgpio_door = 16 MAX31855 K-Type Thermocouple I2Cgpio_sensor_cs = 8 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? |
|
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:
This could all be single instances of problems or a chained reaction to the failure of one instance. 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". |
|
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? |
|
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. |
|
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? |
|
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/ |
|
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). |
|
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: From Firefox I get: Could that be causing the issue? |
|
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 :) |
|
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. |
|
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. |
|
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. |
|
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. |
When I first connect to the server I get two messages:
"Yay, I'm alive" which seems fine and another which says "Error 1: status websocket not available" which is all red and ominous.
I can't see either of the default profiles contained in the storage directory and on the host's terminal I am getting:
2014-12-16 21:20:29,160 ERROR ovenWatcher: could not write to socket <geventwebsocket.websocket.WebSocket object at 0xb4daf110>
I'm not getting sensor readings either. I have a raspberry pi B+ and I changed the config.py to reflect having my adafruit MAX31855 hooked up to the SPI port pins.
The text was updated successfully, but these errors were encountered: