ISY4Me

I do not know the precise answer, but from what I have read the thermocouple output is a very low voltage and the amp reads that signal and provides cold junction compensation and digitizes the output. The output of the MAX31855 (MAX31856 can also be used) or the MAX6675 is then read by the RPi. The hardware design is talked about on many sites and I took the recommendations from what I read. The Maxim data sheet can explain more that I can...https://www.alldatasheet.com/datasheet-pdf/pdf/415787/MAXIM/MAX31855.html

Thank you to all that provided suggestions. Using a k-type thermocouple (design options will limit the highest temp you are monitoring), MAX31855 as the signal amplifier and a Raspberry Pi to read the temperature data from the amplifier… then push the data to the EISY using REST. Both @Guy Lavoie suggestion to use sockets and my original http formatted for EISY REST worked great. I did find one restriction in choosing to use the MAX31855 as the amplifier… it will not allow the use of a grounded thermocouple. If you have a grounded thermocouple you can use the older MAX6675 (discontinued but still available new) and it allows use of grounded thermocouples to extract the data using the Raspberry modules. You will want to be careful which thermocouple you purchase. If you want to go to the max levels of a k-type you will need to be very selective as to the thermocouple construction. If you want to protect the thermocouple from the atmosphere, look at the shielded type, but be aware the shielded design couple limit your max temperature to approximately 500C - 600C due to how it is constructed. A pure ceramic non-shielded thermocouple will probably be the best way to get readings all the way to 1300C.

I quickly isolated that there was an issue with the s.sendall line. After finding a relatively good web document on constructing web links for sockets, I had everything working. When I compared the working s.sendall line to the original I found that there was a syntax error when the original line was copied. With both my original approach using the requests method or the sockets method, do you feel the sockets method will be faster and/or more reliable? At this point I am pleased that both methods are working and I have options. Many thanks.

@Guy Lavoie Thanks Guy… I will work with the issue over the next few days.

I have modified the target EISY IP and the data variable ID and value and the authorization encrypted and I believe that is all. When I run your code it gives me Traceback (most recent call last): File "/home/pi/Programming/MAX31855/FromGuyLavoie.py", line 28, in <module> data = s.recv(1024) socket.timeout: timed out I have compared the files multiple times and see no differences. The only thing I could not find help on is whether or not there is a package I have to install to "import sockets".

I just resolved why the EISY variable was not updating. In the string that sets up the GET line, I was just using the temp variable defined in Python. Originally I wrote the GET Line (abbreviated) /rest/vars/set/2/6/9 I simply replaced the value (9 in your code) with the Python variable. The problem with that is the Python was a floating variable and would not allow a floating variable to be added to a string. After looking deeper, it also appears that the str() command will round off the floating number. To adjust for that I multiply the floating variable by x10 first, then convert to a string then concatenate the data of the variable... so now it looks like /rest/vars/set/2/6' + str(tempF). I will have to think about this as there was similar when using the WebController WC8, so I may end up x100 and then on the EISY side simply divide by 100 to get a xx.xx floating temp. This day has brought more progress than I expected. I will look at your suggest and see which will be more efficient, but it is clear there is a way. Thank you so much... your comments help me thing through what I was try to do as well.

I took a look and understand some of your method. I copied it in Python did the necessary changes and I am getting a timeout on the data = s.recv(1024) line. I noticed that things are running slow right now so I will try again later. On my side I too was able to get the Python code doing mostly what I want. The Python on the RPi does the temp extraction very reliably and has demonstrated that it can push it over to the EISY. The current and hopefully last issue with this approach is when data loops. the EISY will not update the data point, the value has to change for that to occur. Even when I force the state variable to change in the Python code it is not always updating... so a little more work to do there too. I will update you when I can look at your code.

@Guy Lavoie Thanks. No rush, I am happy just to be at this point of determining how to extract the data. I am learning as I go, it is slow, but usually works. Have a good evening.

@Guy Lavoie With my knowledge of Python at the low level as it is, I have to be honest I do not know how to do what you are asking.

@Geddy The K hardware can handle well past 1000F. It appears the problem I have now is getting the output from a Raspberry Pi Python code into the EISY. It is a work in progress and I am sure I will learn more once I get past the point where I am. I seem to be stuck on how to use REST on the RPi running Python to push data to a state variable in EISY.

I did read up on it a little last week, but the temp range stopped me from exploring. I will be monitoring 0F to 1000F.

Thank you @Guy Lavoie, but since there is always going to be some lag in temperatures my objective it to directly monitor the temperature where the flue mounts to the stove. I have experienced some overtires that happen very quickly, so I believe the lag could be a factor. I have made some advances since the original posting. Using a K-Type steel encased probe with insulated cable you will be able to drill a small 1/4" hole in the flue pipe and directly insert the probe. With the k-Type signal being low amplitude, it is recommended to connect it to an amplifier... I used a MAX31855. This morning I connected every thing together on a Raspberry Pi and tested on the workbench and everything works as expected. I did not test with a blow torch, but this k-type probe is listed to work/monitor over 1000C. I put together the python code to extract and display the temperature and that works as well. However not being a fluent Python programmer, I feel I missing the key feature of being able to write that variable to an EISY state variable using REST. I use the Webcontroller WC8 PCL to do this for low temperatures from a DB18B20 thermocouple using the PLC built in settings and that works fine in pushing the temp to the EISY variable. However, trying to emulate that and sending a URL from the Raspberry Pi no data is written. Can any users offer some guidance?

Those that heat or augment their heating with wood stoves are always concerned with control. I use surface temperature probes to monitor the blower air temp, but you have to be watching them. I also use a flue insert probe to monitor the temperature of the gases coming out of the firebox, but again it is a physical readout and you have to physically monitor the performance. Since my stove is in the basement, it concerns me that if an over temp situation is brewing that I could miss it. What I want to do is to use a k-type probe designed for inserting into the flue pipe and capture the temperature reading so my EISY can notify me to address the situation. Insulated k-type thermocouples are widely available and there are lots of discussions about using an Arduino to gather data, but I have not seen discussions about capturing the data and sending it with a REST command to the EISY. I do something similar with the DS18B20 and a WebController CAI 8bit board for monitoring room temperatures and I was looking to see if there was a way to do something similar with a k-type thermocouple Any thoughts?

Thank you @mjrush and @Ross. These both sound like they could be just what I am looking for. I will start researching all the suggestions, including @paulbates inputs.

I have seen discussions relating to the Pushover app before. That sounds like it could be a candidate for a receptor for data. I would just have to explore the possibility and educate myself. Thanks for the suggestion. As far as capturing the data I want… I know there will have to be devices out there. Temperature sensing with the ds18b20 I am already using. I may want to attempt airflow rate as well… that might take some digging. I have a few devices that measure current usage and I think they might report voltage as well, but I will have to research as I have not used that mode if it exists. This is a long term project, so focusing a way to save the data comes first. Data collection devices will be the 2nd stage. Thanks for the suggestion.