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.

I have an issue with one of my heat pumps and I want to try to analyze what data I can capture in an attempt to predict the next failure. I did a search on writing data, but the few discussions that I found seem to assume the user knows what they are doing. What I need is a dummy’s guide. My plan is to setup some voltage and temperature sensors that will allow me to monitor a few points in the system, then based on system events I want to write what data I can capture for a longer term analysis. In the depths of the forum there is tons of info, but does anyone have a step by step perspective on how I would send the targeted data to a simple data file?

When something in my home automation appears to not be working correctly, one of the first things I do is go to UD Mobile and try to view the contents of the suspected programs. However, due to the complexity of how many of the programs are written, I often see something like the following. Seeing this warning message means I need to go to the EISY or my desktop to bring up the Java interface to see the details of what I wrote in the program. Even if I can’t edit my more complex programs in UD Mobile it would be informative if I could see the text of the program so my debugging process can begin. Might it be possible to present something like simple text or PDF in something like a view mode from within UD Mobile?

@Javi Thanks for response. I figured the beta status probably implied there was much work in progress. I will continue to watch and test as updates occur.

I have been experimenting with the new UD Mobile Graphical Charting beta option that was discussed in the recent UD News email. All in all, things are working. I realize that this feature is still in beta, but is there a way to constrain the x-axis, as an example… to the last 24 hours? In the example here I bring up the temperature response for the main thermostat and you can see it defaults to the time window just after 1:00 AM, when the time I did this was 11:30 AM on the same day. I am sure there will be further improvements. I think this ability is great. Currently I do this with Home Assistant… here is an example for the same device. Just a suggestion it would be cool to be able to display the graphical history as a separate object on the Dashboard, as opposed to having to select the device, then the device dashboard and then scroll to the graph. I think this is a great feature and I am looking forward to watching it’s evolution.

Thank you @larryllix... that is essentially what I have done for now. It is a simple solution.

@paulbates Thank you. I saw that and having the status in Climate didn't initially make sense, but I just setup a test case using Climate and the Vacation state and it worked perfectly. @dbwarner5 I agree with your approach. Eventually, I hope to go in an integrate my own Vacation controls into my programs so that everything remains explicitly controlled by the EISY. This is will take some time... and with that in mind, detecting the state and letting the thermostat control vacation settings was a quicker solution. Using the detection to disable folders of HVAC control was just a quick solution.

I want to be able to detect when my Ecobee's are in Vacation Mode. The Vacation Mode controlled my the Vacation setting in the app works great, but I have some programs that could possibly override things and I want to be able to detect the Vacation Mode being enabled so the program folders in question can be set to not run. However, when I try to determine how to detect the Vacation Mode state in EISY, I can't see how to do this. Has anyone attempted to do the same?

Thank you @Ross. Your response helped me understand the basics… I was not even close to thinking age/time since last new moon.

I have the Sun Nodeserver running, but the Moon Phase just reports a number... right now it is showing 18. I have looked for some documentation for this NS and I can not find a valid link. Any input appreciated.

My EISY has been offline for months and this morning I decided to re-activate and update everything. No issues updating the firmware, the UI or PG3 and all appears OK, but I saw the note a few posts back about the "Z-Wave | OTA Firmware Upgrade menu items" being available. I looked at a few z-wave devices and I see nothing regarding the OTA capability. Here is a screen shot of one of the z-wave devices. Perhaps someone can comment on what I am missing.