Only humidity is effected by changes
When the following code runs the get requests indicate loop 1 is temperature, and loop 2 is humidity. However the following post statements both change humidity. Thanks for any help in advance.
import requests
import json
import time
host = '10.24.0.100'
rsp = requests.get('http://%s/api/v1.0/chambers/1/loops/1' % host)
rsp.raise_for_status()
print(rsp.json())
time.sleep(5)
rsp = requests.get('http://%s/api/v1.0/chambers/1/loops/2' % host)
rsp.raise_for_status()
print(rsp.json())
time.sleep(5)
rsp = requests.post(
'http://%s/api/v1.0/chambers/1/loops/1' % host,
data=json.dumps({"N": 1,'enable':True, "controller": 1, "setValue": 45.0}),
headers={"Content-type": "application/json"}
)
rsp.raise_for_status()
time.sleep(30)
rsp = requests.post(
'http://%s/api/v1.0/chambers/1/loops/2' % host,
data=json.dumps({"N": 1,'enable':True, "controller": 1, "setValue": 30.0}),
headers={"Content-type": "application/json"}
)
rsp.raise_for_status()
Comments (8)
-
-
Account Deactivated Thank you for the response. To clarify the current version of the software is 2.2 and version 2.3 will fix this? Also I have since found another bug since first submitting this. Would you like it as a separate submission, a comment here, or an email?
ps I'm the OP of this bug. I was not at a machine to login at the time of submitting.
-
If you are seeing both of those requests in your original response affect humidity then I am not sure what is going on and I can't say that 2.3 will fix it as I was not able to produce that affect (both of those requests affect temperature for me).
As to the other bug a new issue would probably be best.
I have fixed me not getting notifications about issues since my last response.
-
I had another thought, what kind of chamber is your web controller connected to? what options does it have. I just thought of a senario that could do what you described assuming it is a Watlow F4T(BTX-475?) chamber with product temperature control.
-
Account Deactivated Our configuration is the one outlined above.
-
Based on your other issue showing that you do have a chamber with an F4T and product temperature control (watlow calls this cascade control) The following should resolve your issue using 2.2 (untested as we do not have the correct controller on hand for me to test this with at the moment):
import requests import json import time host = '10.24.0.100' rsp = requests.get('http://%s/api/v1.0/chambers/1/loops/1' % host) rsp.raise_for_status() print(rsp.json()) time.sleep(5) rsp = requests.get('http://%s/api/v1.0/chambers/1/loops/2' % host) rsp.raise_for_status() print(rsp.json()) time.sleep(5) rsp = requests.post( 'http://%s/api/v1.0/chambers/1/loops/1' % host, data=json.dumps({"N": 1,'enable':True, "controller": 1, "setValue": 45.0, "enable_cascade":false}), # the "enable_cascade" parameter is required on ptcon/cascade control loops. headers={"Content-type": "application/json"} ) rsp.raise_for_status() time.sleep(30) rsp = requests.post( 'http://%s/api/v1.0/chambers/1/loops/2' % host, data=json.dumps({"N": 1,'enable':True, "controller": 1, "setValue": 30.0}), headers={"Content-type": "application/json"} ) rsp.raise_for_status()
The problems with the api in version 2.2 are not that it doesn't work, they are with that you need to know way to much about how the chamber controller is configured (especially with Watlow F4T based chambers), this provides unexpected results (I don't disagree that it is broken).
-
Account Deactivated I have tested the above solution and it works (False should be capitalized). Thank you for your help and feel free to email me directly at j.diamond-contractor@kyrio.com for any future updates.
-
- changed status to resolved
Closing this as there has been no further discussion and 2.3.0 fixes many of these issues with the API.
- Log in to comment
I just saw this... I didn't realize I had to enable new issue alerts manually; sorry about that.
So both of those requests affect humidity? I am seeing them both affecting temperature. This would happen because the API currently ignores the loop # set in the url and uses the N parameter in the body. so I would expect this to work (The only change being the
"N": 2
on the second request:The web ui itself only ever sets all loops at once so this got missed.
I have fixed this and made the urls actually act as you would expect them to with 2.3.0:
In a week or so I can supply an update file for 2.3.0