Closed greggitter closed 11 months ago
FWIW, I'm seeing similar messages on a fresh install on rpi 32 bit Lite/headless OS. I wrote these messages off (erroneously?) to the fact that my thermostat is not configured with this device as a proxy.
Even with the logged "errors", the web page comes up cleanly (and there is a good api response) for me when the service is launched interactively. Have you tried the port 3000 in a browser?
I’ll give it another shot, thanks.
I agree that those errors shouldn't be spamming your logs, so I'll try to submit a fix for that if I can reproduce the problem. The messages should be irrelevant however unless you're using an rs485 serial adaptor with infinitude.
OK, got a chance to look at this again and in fact it is working...at least the infinitude/server part.
Now the problem is I can't get the thermostat to accept the local server address. I enter it, then the port, touch save and it takes me out of that screen. When I click on it again, it has the old settings still in there (carrier server). I guess I'll need to get with them...looks like a s/w bug on their side. There is a new f/w being released this week for it so I'll probably wait for that and then test again. Thanks for the help!
Just to be clear, what you need to save on the thermostat is the ADDITION of a proxy server. By default, there are no "old settings" to revert to.
Ah...proxy option is on the second page...missed that. Entered the server address and port, but not getting anything in the web page. Checking the router, traffic is passing to port 3000 from the thermostat (different VLANs)...but that was also confusing. Is the port the same for web page and proxy (the default was 8080)...assuming yes? I started the server with this line:
docker run -d -v $PWD/state:/infinitude/state -p 3000:3000 nebulous/infinitude
Status is blank...any diagnostics via CLI I can check? Really appreciate the help! Thx.
I'm not that many steps ahead of you. (My thermostat is off-grid and I'm still trying to get it set up through cell modem.) I'm pretty sure that you will need to set the proxy port to 3000 on the thermostat unless you change your docker run command to map port 3000 to 8080 or whatever you choose.
My understanding is that the thermostat only tries to connect to the carrier server periodically (every 15 minutes?), so if you don't see immediate results when looking for status, you might let things "stabilize" for a bit. @nebulous is the expert!
It's not always clear to new users how Infinitude works so maybe this diagram will help:
Infinitude runs by default on port 3000, both its local web interface, and as a web proxy so that it can intercept the polling traffic between the thermostat and Carrier's servers. Talking to Carrier's servers is something that I don't really do and I become decreasingly interested in problems as they get further up and to the right in this diagram.
So as @jftaylorMn said, your thermostat will need to be able to contact the Infinitude instance on whatever port you select (tends to be 3000). Leave the server settings alone at whatever they're configured to by default (either carrier or bryant or ion) and only add an http proxy to Infinitude.
Very helpful drawing!
Is there a “dummies guide for infinitude”?
I would love to see one.
I’m building a new house with a zoned Bryant (Carrier) zoned system… So I am following this closely :-).
Phil
On Wed, Dec 14, 2022 at 9:47 AM nebulous @.***> wrote:
It's not always clear to new users how Infinitude works so maybe this diagram will help: [image: image] https://user-images.githubusercontent.com/177510/207654976-265552b6-15fa-45d8-942c-07fb65ae733c.png
Infinitude runs by default on port 3000, both its local web interface, and as a web proxy so that it can intercept the polling traffic between the thermostat and Carrier's servers. Talking to Carrier's servers is something that I don't really do and I become decreasingly interested in problems as they get further up and to the right in this diagram.
So as @jftaylorMn https://github.com/jftaylorMn said, your thermostat will need to be able to contact the Infinitude instance on whatever port you select (tends to be 3000). Leave the server settings alone at whatever they're configured to by default (either carrier or bryant or ion) and only add an http proxy to Infinitude.
— Reply to this email directly, view it on GitHub https://github.com/nebulous/infinitude/issues/160#issuecomment-1351755528, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJLON4TZL3DIYHIAPAP65HDWNH2ZDANCNFSM6AAAAAAS5RIU7Y . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Diagram is helpful. I was trying to get the proxy server working so I could then add the homeassistant-infinitude custom control. I seem to have the web page available but no data but do see traffic between the proxy and thermostat, but also getting these errors continuously in the docker container log:
Use of uninitialized value in -e at ./infinitude line 61. Use of uninitialized value in -e at ./infinitude line 61. [2022-12-14 16:52:57.42705] [6] [info] Websocket opened, but no streaming source found Use of uninitialized value in -e at ./infinitude line 61. Use of uninitialized value in -e at ./infinitude line 61.
Seems like something is getting blocked before it's reaching the server (unless the error is diagnostic). I verified the proxmox container changing unprivileged to privileged and disabling the firewall option but didn't make a difference. Not sure what else to try. Thanks!
Use of uninitialized value in -e at ./infinitude line 61.
That error is in fact diagnostic and should be benign for your use case(but I will endeavor to squash it in a forthcoming release, since it's useless and annoying and that code shouldn't run unless one has a SERIAL_TTY
or SERIAL_SOCKET
configured - do ensure that you don't have either of those parameters set, @greggitter) so far as I can tell. If your thermostat is passing messages successfully to Infinitude, and if Infinitude can hit Carrier's webservice, then your state folder should start accumulating request/response data. Infinitude has little control over when/which Carrier calls are sent, but you can try to prod the thermostat into sending its status by changing the temperature at the thermostat.
Hey @nebulous thanks a bunch. I ran a packet capture and there is definitely communication between the therm and infinitude (in one packet I could thermostat model numbers iterated and other attributes but nothing related to my data, i.e., temp, humidity, etc). The state folder is empty. Made several changes to the therm as suggested. I don't suppose there is anything else I can verify. I feel like I've missed something, but I've built the system twice.
I did discover an error in the syslog - "level=error msg="failed to mount overlay: invalid argument" storage-driver=overlay2" which is proxmox-lxc/docker related. To solve this I needed to enable Fuse (for the LXC) and "apt install fuse-overlayfs" (debian). That cleaned that up, I did then reinstall infinitude, but still nothing. I'll keep poking at it to see if I find something.
@philgrocks - This is a classic problem with IT projects like this. @nebulous (and a few others?) have designed and built this to meet the needs and could probably author great technical documentation. Historically, such a document would likely miss the mark for a brand new adopter (like me?). Integration with HomeAssistant is another common thread with some good content in that community. Adding the diagram to the wiki page might help clear the smoke around what is happening. Showing how home assistant comes into the picture may or may not be in scope. Explaining what to expect to find in the state folder might also be of benefit to the newbie trying to troubleshoot.
Here's the benefit of git - if you see something that could be improved (e.g. the wiki pages) and have the skills to do it, you could pull down the repository, make the changes in a new branch and push the changes back to Github. Once there, you could create a pull request that can be reviewed and merged if accepted. I don't have much experience with this project, but do see that a number of authors have contributed pull requests, so assume that @nebulous is open to the community help.
Alternatively, since @nebulous is active in this discussion and says that there is a future update, maybe he can expand the wiki in this area when the next release is ready.
The state folder is empty.
ok that's definitely thread to pull upon. Infinitude writes all requests to Carrier and responses from Carrier to files in the state folder (would probably recommend f2fs and/or a USB flash drive since it's so write-heavy. though the kernel's cache will likely ameliorate this a bit) so I would expect to see items in there. What does /api/state_keys
return?
Also, re: documentation yes! Please contribute. Either to README files with a pull request or directly to the wiki in a web browser. All contributions welcome.
Uh /api/state_keys....? I don't even see that folder, where am I looking. Find command returned nothing.
I'm running this on a small server with nvme drive...I'm not worried about wearing it out. ZFS probably heavily caches it.
To test the API, you just enter the web page url and port in the address bar, followed by /api/state_keys . e.g.
http://Yourserver:3000/api/state_keys
If successful, you will see a json reply, If you have a program like postman you could also use that to test the API.
This one line is all that is returned:
["Alive","Alive.xml","req-Alive.txt","res-Alive.txt","started"]
The currently deploying build 1e2d7c9 should hopefully get rid of some of the log spam.
["Alive","Alive.xml","req-Alive.txt","res-Alive.txt","started"]
indicates that the thermostat has called the /Alive endpoint at least once, but no other endpoints (most importantly systems or status). You should see at least some files related to Alive in your state folder assuming you've mounted said folder as a volume in your docker host. We'll need more information about your configuration to get that sorted, but in the mean time a fresh new version should arrive at a container repo near you in about 10 minutes.
I am least skilled in docker of all things. If something extra needed to be done beyond getting it set up and running the command in the instructions I have not done it. If i should or need to mount a separate volume, I can definitely do that. I found the container instance in var/lib/docker and sifted through that folder. Maybe I’m looking in the wrong place. Thx.
edit: corrected folder
Installed the new version, receiving these new messages. Used this to start the container:
docker run -d -v $PWD/state:/infinitude/state -p 3000:3000 nebulous/infinitude
ODE is set to Production
Use of uninitialized value $host in concatenation (.) or string at ./infinitude line 73.
Use of uninitialized value $port in concatenation (.) or string at ./infinitude line 73.
Using port for serial interface
[2022-12-15 00:36:24.84610] [6] [info] Listening at "http://*:3000"
Use of uninitialized value $host in concatenation (.) or string at ./infinitude line 73.
Use of uninitialized value $port in concatenation (.) or string at ./infinitude line 73.
Using port for serial interface
Use of uninitialized value $host in concatenation (.) or string at ./infinitude line 73.
Use of uninitialized value $port in concatenation (.) or string at ./infinitude line 73.
Using port for serial interface
Use of uninitialized value $host in concatenation (.) or string at ./infinitude line 73.
Use of uninitialized value $port in concatenation (.) or string at ./infinitude line 73.
Using port for serial interface
Use of uninitialized value $host in concatenation (.) or string at ./infinitude line 73.
Use of uninitialized value $port in concatenation (.) or string at ./infinitude line 73.
Using port for serial interface
Use of uninitialized value $host in concatenation (.) or string at ./infinitude line 73.
Use of uninitialized value $port in concatenation (.) or string at ./infinitude line 73.
Using port for serial interface
Thx!
I decided to try to install the app natively. The end results were the same. Not getting any information on the dashboard but do have files in the state folder. Now that I could see some file names, I searched in the docker instance for the file name and found it in /opt/containerd/state. The files in that folder are: [Alive+2exml.dat Alive.dat manifest+2exml.dat manifest.dat req-Alive+2etxt.dat req-manifest+2etxt.dat res-Alive+2etxt.dat res-manifest+2etxt.dat started.dat] and do contain data.
/api/state_keys returns: ["Alive","Alive.xml","manifest","manifest.xml","req-Alive.txt","req-manifest.txt","res-Alive.txt","res-manifest.txt","started"].
Here's some output from the natively installed infinitude (seems only generated when viewing the web page):
root@ct-Other:/opt/infinitude-master # ./infinitude daemon
[2022-12-15 08:00:24.48943] [26069] [info] Listening at "http://*:3000"
Web application available at http://127.0.0.1:3000
[2022-12-15 08:01:06.60403] [26069] [trace] [tqXJn6HEqafV] GET "/"
[2022-12-15 08:01:06.60574] [26069] [trace] [tqXJn6HEqafV] Routing to a callback
[2022-12-15 08:01:06.60704] [26069] [trace] [tqXJn6HEqafV] 200 OK (0.003004s, 332.889/s)
[2022-12-15 08:01:06.71619] [26069] [trace] [_ONIvlDGSJhT] GET "/serial"
[2022-12-15 08:01:06.71797] [26069] [trace] [_ONIvlDGSJhT] Routing to a callback
[2022-12-15 08:01:06.71834] [26069] [info] Websocket opened, but no streaming source found
[2022-12-15 08:01:06.72001] [26069] [trace] [_ONIvlDGSJhT] Template "serial.html.ep" not found
[2022-12-15 08:01:06.72044] [26069] [trace] [_ONIvlDGSJhT] Nothing has been rendered, expecting delayed response
[2022-12-15 08:01:06.73125] [26069] [trace] [yFZQJfWalZ_t] GET "/systems.json"
[2022-12-15 08:01:06.73263] [26069] [trace] [yFZQJfWalZ_t] Routing to a callback
[2022-12-15 08:01:06.73361] [26069] [trace] [yFZQJfWalZ_t] 200 OK (0.002327s, 429.738/s)
[2022-12-15 08:01:06.73599] [26069] [trace] [qXEK6e0kSFVA] GET "/status.json"
[2022-12-15 08:01:06.73710] [26069] [trace] [qXEK6e0kSFVA] Routing to a callback
[2022-12-15 08:01:06.73796] [26069] [trace] [qXEK6e0kSFVA] 200 OK (0.001945s, 514.139/s)
[2022-12-15 08:01:06.74208] [26069] [trace] [rnuTRwgctSJk] GET "/energy.json"
[2022-12-15 08:01:06.74325] [26069] [trace] [rnuTRwgctSJk] Routing to a callback
[2022-12-15 08:01:06.74415] [26069] [trace] [rnuTRwgctSJk] 200 OK (0.002039s, 490.436/s)
[2022-12-15 08:01:06.74658] [26069] [trace] [yZjMetZKjQmN] GET "/notifications.json"
[2022-12-15 08:01:06.74772] [26069] [trace] [yZjMetZKjQmN] Routing to a callback
[2022-12-15 08:01:06.74860] [26069] [trace] [yZjMetZKjQmN] 200 OK (0.001996s, 501.002/s)
[2022-12-15 08:01:25.64752] [26069] [trace] [ZIwwtnX7SkMN] GET "/"
[2022-12-15 08:01:25.64827] [26069] [trace] [ZIwwtnX7SkMN] Routing to a callback
[2022-12-15 08:01:25.64959] [26069] [trace] [ZIwwtnX7SkMN] 304 Not Modified (0.002045s, 488.998/s)
[2022-12-15 08:01:25.72054] [26069] [trace] [lH79qMXUb_NQ] GET "/serial"
[2022-12-15 08:01:25.72082] [26069] [trace] [lH79qMXUb_NQ] Routing to a callback
[2022-12-15 08:01:25.72089] [26069] [info] Websocket opened, but no streaming source found
[2022-12-15 08:01:25.72119] [26069] [trace] [lH79qMXUb_NQ] Template "serial.html.ep" not found
[2022-12-15 08:01:25.72131] [26069] [trace] [lH79qMXUb_NQ] Nothing has been rendered, expecting delayed response
[2022-12-15 08:01:25.73254] [26069] [trace] [qGxEzBc0Sp9N] GET "/systems.json"
[2022-12-15 08:01:25.73286] [26069] [trace] [qGxEzBc0Sp9N] Routing to a callback
[2022-12-15 08:01:25.73325] [26069] [trace] [qGxEzBc0Sp9N] 200 OK (0.000709s, 1410.437/s)
[2022-12-15 08:01:25.73493] [26069] [trace] [lJIaiV7JTPjJ] GET "/status.json"
[2022-12-15 08:01:25.73519] [26069] [trace] [lJIaiV7JTPjJ] Routing to a callback
[2022-12-15 08:01:25.73558] [26069] [trace] [lJIaiV7JTPjJ] 200 OK (0.000632s, 1582.278/s)
[2022-12-15 08:01:25.73664] [26069] [trace] [mqng9ElTe-bm] GET "/notifications.json"
[2022-12-15 08:01:25.73701] [26069] [trace] [mqng9ElTe-bm] Routing to a callback
[2022-12-15 08:01:25.73740] [26069] [trace] [mqng9ElTe-bm] 200 OK (0.00075s, 1333.333/s)
[2022-12-15 08:01:25.73845] [26069] [trace] [XKtQBOHKKEHo] GET "/energy.json"
[2022-12-15 08:01:25.73871] [26069] [trace] [XKtQBOHKKEHo] Routing to a callback
[2022-12-15 08:01:25.73909] [26069] [trace] [XKtQBOHKKEHo] 200 OK (0.000625s, 1600.000/s)
[2022-12-15 08:01:36.72159] [26069] [trace] Inactivity timeout
[2022-12-15 08:01:43.00551] [26069] [trace] [jJAR7VP1S2MQ] GET "/api/state_keys"
[2022-12-15 08:01:43.00630] [26069] [trace] [jJAR7VP1S2MQ] Routing to a callback
[2022-12-15 08:01:43.00689] [26069] [trace] [jJAR7VP1S2MQ] 200 OK (0.0014s, 714.286/s)
[2022-12-15 08:01:45.72773] [26069] [trace] [SGxZDMPGlvtv] GET "/"
[2022-12-15 08:01:45.72848] [26069] [trace] [SGxZDMPGlvtv] Routing to a callback
[2022-12-15 08:01:45.72955] [26069] [trace] [SGxZDMPGlvtv] 200 OK (0.001791s, 558.347/s)
[2022-12-15 08:01:46.75321] [26069] [trace] [EAopvc4Ix9i_] GET "/serial"
[2022-12-15 08:01:46.75394] [26069] [trace] [EAopvc4Ix9i_] Routing to a callback
[2022-12-15 08:01:46.75430] [26069] [info] Websocket opened, but no streaming source found
[2022-12-15 08:01:46.75495] [26069] [trace] [EAopvc4Ix9i_] Template "serial.html.ep" not found
[2022-12-15 08:01:46.75536] [26069] [trace] [EAopvc4Ix9i_] Nothing has been rendered, expecting delayed response
[2022-12-15 08:01:46.75930] [26069] [trace] [TznaZtrhz6Wx] GET "/systems.json"
[2022-12-15 08:01:46.76004] [26069] [trace] [TznaZtrhz6Wx] Routing to a callback
[2022-12-15 08:01:46.76100] [26069] [trace] [TznaZtrhz6Wx] 200 OK (0.001665s, 600.601/s)
[2022-12-15 08:01:46.76510] [26069] [trace] [taEYKWyIEK1o] GET "/energy.json"
[2022-12-15 08:01:46.76572] [26069] [trace] [taEYKWyIEK1o] Routing to a callback
[2022-12-15 08:01:46.76659] [26069] [trace] [taEYKWyIEK1o] 200 OK (0.001462s, 683.995/s)
[2022-12-15 08:01:46.76909] [26069] [trace] [7Dx4kOGQNvjb] GET "/status.json"
[2022-12-15 08:01:46.76970] [26069] [trace] [7Dx4kOGQNvjb] Routing to a callback
[2022-12-15 08:01:46.77057] [26069] [trace] [7Dx4kOGQNvjb] 200 OK (0.001444s, 692.521/s)
[2022-12-15 08:01:46.77311] [26069] [trace] [9gRBYLtJjApv] GET "/notifications.json"
[2022-12-15 08:01:46.77372] [26069] [trace] [9gRBYLtJjApv] Routing to a callback
[2022-12-15 08:01:46.77458] [26069] [trace] [9gRBYLtJjApv] 200 OK (0.001444s, 692.521/s)
[2022-12-15 08:01:55.72184] [26069] [trace] Inactivity timeout
[2022-12-15 08:02:16.75651] [26069] [trace] Inactivity timeout
[2022-12-15 08:02:47.00015] [26069] [trace] [Tue36iCxydNS] GET "/"
[2022-12-15 08:02:47.00091] [26069] [trace] [Tue36iCxydNS] Routing to a callback
[2022-12-15 08:02:47.00199] [26069] [trace] [Tue36iCxydNS] 200 OK (0.001798s, 556.174/s)
[2022-12-15 08:02:47.15129] [26069] [trace] [BlLsk25O9w-F] GET "/serial"
[2022-12-15 08:02:47.15209] [26069] [trace] [BlLsk25O9w-F] Routing to a callback
[2022-12-15 08:02:47.15248] [26069] [info] Websocket opened, but no streaming source found
[2022-12-15 08:02:47.15313] [26069] [trace] [BlLsk25O9w-F] Template "serial.html.ep" not found
[2022-12-15 08:02:47.15352] [26069] [trace] [BlLsk25O9w-F] Nothing has been rendered, expecting delayed response
[2022-12-15 08:02:47.15547] [26069] [trace] [Vc0Mqq7riZ5z] GET "/systems.json"
[2022-12-15 08:02:47.15608] [26069] [trace] [Vc0Mqq7riZ5z] Routing to a callback
[2022-12-15 08:02:47.15699] [26069] [trace] [Vc0Mqq7riZ5z] 200 OK (0.001488s, 672.043/s)
[2022-12-15 08:02:47.15987] [26069] [trace] [Yd__Kw5UoXxR] GET "/notifications.json"
[2022-12-15 08:02:47.16050] [26069] [trace] [Yd__Kw5UoXxR] Routing to a callback
[2022-12-15 08:02:47.16137] [26069] [trace] [Yd__Kw5UoXxR] 200 OK (0.001468s, 681.199/s)
[2022-12-15 08:02:47.16383] [26069] [trace] [H8Ix4zXKKhDz] GET "/energy.json"
[2022-12-15 08:02:47.16443] [26069] [trace] [H8Ix4zXKKhDz] Routing to a callback
[2022-12-15 08:02:47.16529] [26069] [trace] [H8Ix4zXKKhDz] 200 OK (0.001435s, 696.864/s)
[2022-12-15 08:02:47.16749] [26069] [trace] [Jal2zu4uMtEc] GET "/status.json"
[2022-12-15 08:02:47.16810] [26069] [trace] [Jal2zu4uMtEc] Routing to a callback
[2022-12-15 08:02:47.16895] [26069] [trace] [Jal2zu4uMtEc] 200 OK (0.001438s, 695.410/s)
[2022-12-15 08:03:07.15085] [26069] [trace] [-zNBDg_d1p9d] GET "/"
[2022-12-15 08:03:07.15164] [26069] [trace] [-zNBDg_d1p9d] Routing to a callback
[2022-12-15 08:03:07.15286] [26069] [trace] [-zNBDg_d1p9d] 304 Not Modified (0.001982s, 504.541/s)
[2022-12-15 08:03:07.27238] [26069] [trace] [CamnjDE0ZDm9] GET "/systems.json"
[2022-12-15 08:03:07.27330] [26069] [trace] [CamnjDE0ZDm9] Routing to a callback
[2022-12-15 08:03:07.27444] [26069] [trace] [CamnjDE0ZDm9] 200 OK (0.002033s, 491.884/s)
[2022-12-15 08:03:07.27940] [26069] [trace] [6_s-ejihclcb] GET "/notifications.json"
[2022-12-15 08:03:07.28022] [26069] [trace] [6_s-ejihclcb] Routing to a callback
[2022-12-15 08:03:07.28130] [26069] [trace] [6_s-ejihclcb] 200 OK (0.001872s, 534.188/s)
[2022-12-15 08:03:07.28460] [26069] [trace] [_EyXFDH6DziW] GET "/energy.json"
[2022-12-15 08:03:07.28539] [26069] [trace] [_EyXFDH6DziW] Routing to a callback
[2022-12-15 08:03:07.28646] [26069] [trace] [_EyXFDH6DziW] 200 OK (0.001836s, 544.662/s)
[2022-12-15 08:03:07.28915] [26069] [trace] [Mox33k-M4boH] GET "/status.json"
[2022-12-15 08:03:07.28977] [26069] [trace] [Mox33k-M4boH] Routing to a callback
[2022-12-15 08:03:07.29065] [26069] [trace] [Mox33k-M4boH] 200 OK (0.00147s, 680.272/s)
[2022-12-15 08:03:07.35206] [26069] [trace] [xcAJMBhblMXb] GET "/serial"
[2022-12-15 08:03:07.35280] [26069] [trace] [xcAJMBhblMXb] Routing to a callback
[2022-12-15 08:03:07.35317] [26069] [info] Websocket opened, but no streaming source found
[2022-12-15 08:03:07.35382] [26069] [trace] [xcAJMBhblMXb] Template "serial.html.ep" not found
[2022-12-15 08:03:07.35421] [26069] [trace] [xcAJMBhblMXb] Nothing has been rendered, expecting delayed response
[2022-12-15 08:03:17.15497] [26069] [trace] Inactivity timeout
[2022-12-15 08:03:27.35803] [26069] [trace] [_8AGmA8R4JF5] GET "/"
[2022-12-15 08:03:27.35879] [26069] [trace] [_8AGmA8R4JF5] Routing to a callback
[2022-12-15 08:03:27.36002] [26069] [trace] [_8AGmA8R4JF5] 304 Not Modified (0.001962s, 509.684/s)
[2022-12-15 08:03:27.51971] [26069] [trace] [bEn-OWqoM-V-] GET "/systems.json"
[2022-12-15 08:03:27.52061] [26069] [trace] [bEn-OWqoM-V-] Routing to a callback
[2022-12-15 08:03:27.52156] [26069] [trace] [bEn-OWqoM-V-] 200 OK (0.001822s, 548.847/s)
[2022-12-15 08:03:27.52403] [26069] [trace] [aNWGHB0QUVcU] GET "/energy.json"
[2022-12-15 08:03:27.52467] [26069] [trace] [aNWGHB0QUVcU] Routing to a callback
[2022-12-15 08:03:27.52554] [26069] [trace] [aNWGHB0QUVcU] 200 OK (0.001478s, 676.590/s)
[2022-12-15 08:03:27.52799] [26069] [trace] [1R8rv2SqctzH] GET "/status.json"
[2022-12-15 08:03:27.52860] [26069] [trace] [1R8rv2SqctzH] Routing to a callback
[2022-12-15 08:03:27.52947] [26069] [trace] [1R8rv2SqctzH] 200 OK (0.001443s, 693.001/s)
[2022-12-15 08:03:27.53210] [26069] [trace] [T7k6Mdcnb03-] GET "/notifications.json"
[2022-12-15 08:03:27.53271] [26069] [trace] [T7k6Mdcnb03-] Routing to a callback
[2022-12-15 08:03:27.53357] [26069] [trace] [T7k6Mdcnb03-] 200 OK (0.001442s, 693.481/s)
[2022-12-15 08:03:27.66092] [26069] [trace] [6RKfWR9IMCkQ] GET "/serial"
[2022-12-15 08:03:27.66165] [26069] [trace] [6RKfWR9IMCkQ] Routing to a callback
Results:
Compatibility issue? Model: SYSTXCCWIC01-B. Thx.
@nebulous, in another support thread you requested output from prove -v. Here is mine...maybe it helps. Thx.
root@ct-Other:/opt/infinitude-master # prove -v
t/00-depends.t ............
ok 1 - require CHI;
ok 2 - require DateTime;
ok 3 - require Hash::AsObject;
ok 4 - require IO::File;
ok 5 - require JSON;
ok 6 - require Moo;
ok 7 - require Mojolicious::Lite;
ok 8 - require Mojo::JSON;
ok 9 - require Path::Tiny;
ok 10 - require Try::Tiny;
ok 11 - require Time::HiRes;
ok 12 - require XML::Simple;
ok 13 - require XML::Simple::Minded;
1..13
ok
t/01-xml-simple-minded.t ..
ok 1 - use XML::Simple::Minded;
ok 2 - An object of class 'XML::Simple::Minded' isa 'XML::Simple::Minded'
ok 3 - contents
ok 4 - attributes
ok 5 - empty tags are self-closing
ok 6 - self-closing tags are clean
ok 7 - XML parses
ok 8 - New values added
ok 9 - xml stringifies definition
ok 10 - xml stringifies system
ok 11 - new test item added
ok 12 - XML is unmangled
1..12
ok
t/system-post.t ...........
1..9
[2022-12-15 12:37:07.23185] [28244] [trace] [9h5OhYBERZBC] GET "/"
[2022-12-15 12:37:07.23255] [28244] [trace] [9h5OhYBERZBC] Routing to a callback
[2022-12-15 12:37:07.23312] [28244] [trace] [9h5OhYBERZBC] 200 OK (0.001276s, 783.699/s)
ok 1 - GET /
ok 2 - 200 OK
[2022-12-15 12:37:07.23601] [28244] [trace] [4c2KmfV0E9ON] GET "/Alive"
[2022-12-15 12:37:07.23649] [28244] [trace] [4c2KmfV0E9ON] Routing to a callback
[2022-12-15 12:37:07.23678] [28244] [trace] [4c2KmfV0E9ON] 200 OK (0.000761s, 1314.060/s)
ok 3 - GET /Alive
ok 4 - 200 OK
ok 5 - exact match for content
[2022-12-15 12:37:07.24463] [28244] [trace] [5113LIqq-Tk7] POST "/systems/systems17test"
[2022-12-15 12:37:07.24518] [28244] [trace] [5113LIqq-Tk7] Routing to a callback
[2022-12-15 12:37:07.24547] [28244] [trace] [5113LIqq-Tk7] 200 OK (0.000835s, 1197.605/s)
ok 6 - POST /systems/systems17test
[2022-12-15 12:37:07.24761] [28244] [trace] [AbFPjsdvreNv] GET "/systems.xml"
[2022-12-15 12:37:07.24820] [28244] [trace] [AbFPjsdvreNv] Routing to a callback
[2022-12-15 12:37:07.24864] [28244] [trace] [AbFPjsdvreNv] 200 OK (0.001017s, 983.284/s)
ok 7 - GET /systems.xml
ok 8 - 200 OK
File does not exist: Infinitude doesn't know how to GET systems.xml at t/system-post.t line 29.
# Looks like your test exited with 2 just after 8.
Dubious, test returned 2 (wstat 512, 0x200)
Failed 1/9 subtests
Test Summary Report
-------------------
t/system-post.t (Wstat: 512 Tests: 8 Failed: 0)
Non-zero exit status: 2
Parse errors: Bad plan. You planned 9 tests but ran 8.
Files=3, Tests=33, 2 wallclock secs ( 0.04 usr 0.00 sys + 1.39 cusr 0.12 csys = 1.55 CPU)
Result: FAIL
It's always possible that your thermostat has some version of firmware that's slightly incompatible, but based on the above test output it looks like something is wrong with the installation itself since the test cycle didn't complete.
I'll startup a new unconfigured instance and see if anything funky happens from a standing start. ⌛️ ok I did that on a separate computer and did see a few warning messages being dumped to the logs, so I'll address those as well in a bit, but after configuring my thermostat to point to the new instance it JustWorked™ 🤔
I just ran tests in my docker container and they did pass, but there was a bug which caused tests to fail on a new install. Fixed that as well as squashing a few more spammy log messages and a pretty ugly dangling timer reference which would only apply to those using a serial adaptor. new images building now. I don't see any reason why any of the aforementioned changes would solve your dilemma, but at least debugging should be easier to look at.
here's my output(sans the warning logspam) to demonstrate how we might expect yours to work eventually
docker run --rm -v $PWD/state:/infinitude/state -p 3000:3000 nebulous/infinitude
[2022-12-16 01:55:13.04248] [7] [info] Websocket opened, but no streaming source found
[2022-12-16 01:55:18.30486] [7] [info] No cache for Alive. Make Carrier request
[2022-12-16 01:55:18.53790] [7] [info] /Alive?sn=123MYSERIAL456
[2022-12-16 01:55:27.69530] [7] [info] No cache for systems-123MYSERIAL456. Make Carrier request
[2022-12-16 01:55:28.22031] [7] [info] /systems/123MYSERIAL456
[2022-12-16 01:55:28.24067] [7] [info] Saving 123MYSERIAL456
[2022-12-16 01:55:37.44422] [7] [info] No cache for systems-123MYSERIAL456-profile. Make Carrier request
[2022-12-16 01:55:37.76408] [7] [info] /systems/123MYSERIAL456/profile
[2022-12-16 01:55:37.76509] [7] [info] Saving profile
[2022-12-16 01:55:37.78092] [7] [info] Unimplemented request: profile
[2022-12-16 01:55:38.78568] [7] [info] No cache for systems-123MYSERIAL456-dealer. Make Carrier request
[2022-12-16 01:55:39.09873] [7] [info] /systems/123MYSERIAL456/dealer
[2022-12-16 01:55:39.10012] [7] [info] Saving dealer
[2022-12-16 01:55:39.12702] [7] [info] Unimplemented request: dealer
[2022-12-16 01:55:40.27110] [7] [info] No cache for systems-123MYSERIAL456-idu_config. Make Carrier request
[2022-12-16 01:55:40.57587] [7] [info] /systems/123MYSERIAL456/idu_config
[2022-12-16 01:55:40.57667] [7] [info] Saving idu_config
[2022-12-16 01:55:40.59311] [7] [info] Unimplemented request: idu_config
[2022-12-16 01:55:41.79370] [7] [info] No cache for systems-123MYSERIAL456-odu_config. Make Carrier request
[2022-12-16 01:55:42.24735] [7] [info] /systems/123MYSERIAL456/odu_config
[2022-12-16 01:55:42.24841] [7] [info] Saving odu_config
[2022-12-16 01:55:42.27671] [7] [info] Unimplemented request: odu_config
[2022-12-16 01:55:43.18098] [7] [info] Websocket opened, but no streaming source found
[2022-12-16 01:55:43.28923] [7] [info] No cache for weather-22039-forecast. Make Carrier request
[2022-12-16 01:55:43.51471] [7] [info] /weather/22039/forecast
[2022-12-16 01:55:45.48722] [7] [info] No cache for systems-123MYSERIAL456-status. Make Carrier request
[2022-12-16 01:55:45.80824] [7] [info] /systems/123MYSERIAL456/status
[2022-12-16 01:55:45.81129] [7] [info] Saving status
[2022-12-16 01:55:45.84595] [7] [info] ********** Check Carrier/Bryant change flags ****************
[2022-12-16 01:55:47.08597] [7] [info] No cache for time-. Make Carrier request
[2022-12-16 01:55:47.28809] [7] [info] /time/
[2022-12-16 01:55:48.30052] [7] [info] No cache for systems-123MYSERIAL456-utility_events. Make Carrier request
[2022-12-16 01:55:48.52919] [7] [info] /systems/123MYSERIAL456/utility_events
[2022-12-16 01:55:48.52970] [7] [info] Unimplemented request: utility_events
[2022-12-16 01:55:50.67447] [7] [info] No cache for manifest. Make Carrier request
[2022-12-16 01:55:51.07540] [7] [info] /manifest
[2022-12-16 01:55:59.18293] [7] [info] No cache for releaseNotes-systxccit-14.02.txt. Make Carrier request
[2022-12-16 01:55:59.39664] [7] [info] http://www.ota.ing.carrier.com/releaseNotes/systxccit-14.02.txt
[2022-12-16 01:56:13.28987] [7] [info] Websocket opened, but no streaming source found
[2022-12-16 01:56:28.44086] [7] [info] systems-123MYSERIAL456-status cached or passthru disabled
[2022-12-16 01:56:28.44130] [7] [info] /systems/123MYSERIAL456/status
[2022-12-16 01:56:28.44969] [7] [info] Saving status
[2022-12-16 01:56:43.39310] [7] [info] Websocket opened, but no streaming source found
[2022-12-16 01:57:00.47923] [7] [info] systems-123MYSERIAL456-status cached or passthru disabled
[2022-12-16 01:57:00.47963] [7] [info] /systems/123MYSERIAL456/status
[2022-12-16 01:57:00.48346] [7] [info] Saving status
[2022-12-16 01:57:13.50015] [7] [info] Websocket opened, but no streaming source found
[2022-12-16 01:57:32.72817] [7] [info] systems-123MYSERIAL456-status cached or passthru disabled
[2022-12-16 01:57:32.72888] [7] [info] /systems/123MYSERIAL456/status
so you can see it first calls the /Alive endpoint with my redacted serial number, then goes thru a series of posts up to the cloud about my config, pulls a manifest for a new firmware (which I'm disinclined to install since things are working with this one 😄 ), gets the weather for my zip etc.
OK...tried now to install via docker on an rpi4 to see if I could get anything working. Same results. Messages today are different with the new changes:
[2022-12-16 16:25:27.30543] [8] [info] Alive cached or passthru disabled
[2022-12-16 16:25:27.30690] [8] [info] /Alive?sn=xxxxxxxxxxxxxx
[2022-12-16 16:25:27.81801] [8] [info] manifest cached or passthru disabled
[2022-12-16 16:25:27.81938] [8] [info] /manifest
[2022-12-16 16:25:54.05243] [8] [info] Websocket opened, but no streaming source is available
I looked in the code but not sure what "manifest cached or passthru disabled" means. Is this indicating a problem? I'm thinking more and more this is a therm s/w issue. BTW, I'm on 4.17 and offered 4.31 now but was waiting for release notes. Maybe I should go for it...I've reached out to carrier but their support is weak (was told it would be up yesterday but it isn't). Thanks!
manifest cached or passthru disabled
To both be a good citizen to Carrier's cloud service, and to increase performance for many of us who don't use the cloud service, all requests/replies to Carrier from the thermostat are cached in the state folder and only sent up to the mothership after a timeout of PASS_REQS
seconds per request. So that message is just saying "ah, a call to /manifest eh?, well either it's cached
already from a previous call and we've yet to hit the ttl, or PASS_REQS is zero iepassthru disabled
so don't make any calls up to Carrier's servers for this request"
so tl;dr; that's not an error, just logging.
It is a good sign that the /Alive?sn=xxxxxxxxxxxxxx
message is being called (tangentially I have no idea why we all redact our serial numbers. I do it too because it somehow feels private, but 🤷 )
I would expect your state folder to contain something like
state/Alive+2exml.dat
state/Alive.dat
state/req-Alive+2etxt.dat
state/res-Alive+2etxt.dat
after the Alive call. Incidentally, everything stored in state
can be returned from Infinitude via the web, even the raw requests and responses. That is, if you hit http://yourip:3000/req-Alive.txt
infinitude will show you the entire request as it was sent to Carrier - headers and all.
Yes, the files (now using the rpi4+docker) are in my home folder:
pi@Rpi-1:~/state $ ls -l
total 52
-rw-r--r-- 1 root root 19 Dec 16 13:13 Alive+2exml.dat
-rw-r--r-- 1 root root 30 Dec 16 13:13 Alive.dat
-rw-r--r-- 1 root root 9142 Dec 16 11:17 manifest+2exml.dat
-rw-r--r-- 1 root root 30 Dec 16 11:17 manifest.dat
-rw-r--r-- 1 root root 464 Dec 16 13:13 req-Alive+2etxt.dat
-rw-r--r-- 1 root root 438 Dec 16 11:17 req-manifest+2etxt.dat
-rw-r--r-- 1 root root 391 Dec 16 13:13 res-Alive+2etxt.dat
-rw-r--r-- 1 root root 9592 Dec 16 11:17 res-manifest+2etxt.dat
-rw-r--r-- 1 root root 29 Dec 16 11:16 started.dat
req-Alive.txt contents:
GET /Alive?sn=xxxxxxxxxxxx HTTP/1.1
Authorization: OAuth realm="http://www.api.ing.carrier.com/Alive?sn=xxxxxxxxxxxxxxxx",oauth_consumer_key="xxx3i0d2l9e7r587",oauth_nonce="xxx121804414854",oauth_signature_method="HMAC-SHA1",oauth_timestamp="xxx1218044",oauth_token="xxxxxxx",oauth_version="1.0",oauth_signature="xxxaf9cmDHnn%2BLzKJt%2FwCQuPkxxxx"
Host: www.api.ing.carrier.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
So at what point would I see information on the web page...still blank aside from the two gauge objects. If I get this working I'll document the other parts for proxmox (if I can get that working too). And yeah, I don't know if anything needs redacted or not. Is there anything else I can verify? Thanks a bunch, really appreciate the help!
Edit: Firmware updated, no difference.
@nebulous, not knowing perl, I was wondering if there is some way I can add some additional query/debug/dump some output to see if it's possible to track down why in my particular case I'm not getting any basic output from thermostat, yet it seems to be communicating fine. Thanks.
So at what point would I see information on the web page
You'll see additional information on the infinitude web page as soon as your thermostat sends its /systems
and /status
posts, which in my case above you'll see happens immediately after the /Alive call. Does your thermostat say "connected" under features->my infinity? I would guess that it doesn't right now based on your state contents. I do recall that Carrier attempted to setup MQTT control in a recent firmware update, but ended up rolling it back - or at least there was one pretty nutty firmware version that broke. See this thread for discussion - specifically this post about that. (edit: I see you're actually on that firmware version 4.17
- so that may well be the issue. Downgrading would be preferred, but upgrading may also work. I live in fear of Carrier's "upgrades")
not knowing perl, I was wondering if there is some way I can add some additional query/debug/dump some output to see if it's possible to track down why in my particular case I'm not getting any basic output
The best output is really the state folder as it contains all requests that the thermostat makes req-*
, their corresponding responses res-*
, and the serialized versions of said responses in both original xml and translated json forms.
more logging output will also be dumped by changing the mode from production
to development
, ie
./infinitude daemon-m development
Does your thermostat say "connected" under features->my infinity?
Yes, it says connected.
I see you're actually on that firmware version 4.17
They posted the change notes late friday, and I went forward and upgraded to 4.31...but it made no difference. Based on some of the fixes since I've owned it (about 10 months), I don't really like the idea of rolling back. I did get a cable to run a hardware to USB for serial input. Maybe that will help (?).
They posted the change notes late friday, and I went forward and upgraded to 4.31...but it made no difference
boo. 👎
I did get a cable to run a hardware to USB for serial input. Maybe that will help (?).
That won't help with this particular problem, but may allow for an alternate means of direct control once I eventually write some software to do so. At present, Infinitude only scans the thermostat via serial, doesn't control it.
I don't need to control it, I just want to monitor basically. The set program rarely needs tweeked...I can always use the app for remote changes. I would like to know how often it cycles, modes, fan speed, etc...if possible.
State folder contents:
Alive+2exml.dat Alive.dat manifest+2exml.dat manifest.dat req-Alive+2etxt.dat req-manifest+2etxt.dat res-Alive+2etxt.dat res-manifest+2etxt.dat started.dat
res-Alive+2etxt.dat contents:
<8D>u<A0>c<FF><FF><FF><FF><FF><FF><FF><FF>^@^AHTTP/1.1 200 OK
Content-Length: 5
Connection: keep-alive
Date: Mon, 19 Dec 2022 14:30:37 GMT
Via: 1.1 3500e6db5ae43764ed5ca43fc6d56058.cloudfront.net (CloudFront)
X-Cache: Miss from cloudfront
X-Amz-Cf-Id: qzlPph-mnI3TXggs2br0uXxLFJUkdPr0K_F5TpkMGLmdFKDAPnEyYg==
X-Amz-Cf-Pop: IAD89-P1
Content-Type: text/plain; charset=utf-8
Apigw-Requestid: dZdOIhuuIAMEYYA=
alive
Doesn't tell me much, obviously no useful data in it. Am I the only one having this issue...weird. Thanks!
@nebulous, I'm overly stubborn about getting this to work. I decided to revert back to using the natively installed (no docker) infinitude I have on a proxmox instance. I shut down the docker version running on the pi for several days now with nothing and started up the proxmox server. I changed the thermostat to point to the new one and suddenly, I had a third empty graph on the main web page and everything populated in Comfort Profiles and Schedules. I did nothing else different. I had additional files in the state folder. After an hour or so, it didn't populate anything further. I stopped the server, moved all the files in the state folder to a hold area elsewhere and restarted the server. Again, I'm back to no data. Any idea what's going on with that? Thanks!
@nebulous the issue appears to be firmware. I went to set up a new integration and had the same issue as @greggitter with the blank status screen. Firmware was 4.31 on B Series Carrier. I flashed to 4.05 and everything works great now. All my settings were correct including the portainer setup, etc. All I did was flash to 4.05 and everything works. Hopefully this helps some others.
Another update...rolled firmware back to 4.05 and that solved it. @nebulous, how can I coherently report this problem to carrier so they can get it fixed? I wonder if it's just a matter of saying the proxy server option is broken after 4.05? Thanks for the help on this!
edit: I hadn't seen the post above before posting this.
Good that you have finally found a workaround! Especially if you have the solution running on Proxmox and Docker, that might be really good to document for the next person interested in going that route.
It seems quite possible that Carrier will not want to "fix" this issue, since they might feel that earlier firmware versions (that work with infinitude) expose the system to a "man in the middle" vulnerability (or, opportunity our case). I have yet to see a reason to update firmware on my system (that is not internet connected), and have little interest in sending my home data to the cloud. I probably won't update firmware until there is a simpler path to communicate with the thermostat (e.g. from an esp8266 or esp32).
I think the request that might get Carrier to move from their proprietary cloud solution would be to ask for support for MQTT and/or Matter. Matter might be shiny enough to convince their marketers to adopt an industry wide home automation standard. Somehow, I don't think it will.
Another update...rolled firmware back to 4.05 and that solved it. @nebulous, how can I coherently report this problem to carrier so they can get it fixed? I wonder if it's just a matter of saying the proxy server option is broken after 4.05? Thanks for the help on this!
I really don't think Carrier will have any interest in supporting Infinitude, and may have an interest in ensuring it breaks if their attention is called to the matter. The only situation wherein I can imagine Carrier would want to put effort into fixing a bug applicable to Infinitude is if their mobile apps were also broken by a typical proxy setup - not Infinitude's proxy+rewrites.
I would guess that newer firmwares use MQTT over a different pipe such that the http proxy settings weren't applicable vs thier being broken. Indeed, some requests were in fact emanating from the thermostat and traversing Infinitude, which implies to me that the proxy settings were working.
and yeah, Matter support would be nice, but I'm not holding my breath. This does underscore my desire to get InfinitESP going (in my copious free time 😆 ) though. So I'd appreciate it if anyone with Infinitude and an RS485 connection could provide some table dumps the 0040 space - 00 40 0A
in particular.
@jftaylorMn, running Docker in a proxmox LXC was straight-forward, I just following standard instructions for installing docker (and then portainer). I also installed natively (without Docker) and that was trickier due to packages needing installed. That was done as follows starting with a standard debian LXC image (or even on Rpi or VM):
cd /opt
git clone https://github.com/nebulous/infinitude
apt install libchi-perl libdatetime-perl libxml-simple-perl libmojolicious-perl libpath-tiny-perl libhash-asobject-perl libjson-perl libdata-parsebinary-perl libdigest-crc-perl
cd infinitude
./infinitude daemon
(or use this to run in background)
./infinitude daemon -m production &>/dev/null &
So if someone wants to skip docker, this works. I also installed cpanminus but never used it so I would try without first. If dependencies are missing, add it and try again. A proxmox LXC may not work with a serial connection, haven't tested that.
I did open a ticket with Carrier regarding the new f/w proxy issue. I agree with you both (@nebulous) they probably will not assist or consider fixing/re-enabling it. Again thanks for all the help!
@nebulous, once I get the serial connection set up, if you could explain what you need and how to get it I can help out. As strange as it seems, my background is IT (developer) up until around 2005.
This does underscore my desire to get InfinitESP going (in my copious free time) though.
@nebulous - With the chip shortage driving up prices, and scarcity of RPi devices, this sounds intriguing. I would be interested in your plans as the project progresses. Are you thinking that the ESP would skip the thermostat and communicate via the controller board/rs485 connection? Unfortunately, I'm not it a position to help with the table dumps since my Carrier furnace is far away, and when I'm there, internet access is scarce.
@nebulous, once I get the serial connection set up, if you could explain what you need and how to get it I can help out. As strange as it seems, my background is IT (developer) up until around 2005.
@greggitter sure, once you get an rs485 adaptor setup, all you need do is go to the Serial tab and enter 00400A
into the virtual SAM box like so:
which with any luck will result in a response being returned. Or better yet, set the SCAN_THERMOSTAT environment variable and leave Infinitude running in a tab for a couple of hours. Ideally it will pull all of the tables it can from the thermostat (including plaintext wifi ssid/password 🙄) which should help in deciphering structures.
and yes, obviously I can tell you are/were a developer, because no sane person who values their time would be so tenacious in figuring out what's causing something to not work. This kind of stubbornness is why we're all able to have nice things.
With the chip shortage driving up prices, and scarcity of RPi devices, this sounds intriguing. I would be interested in your plans as the project progresses. Are you thinking that the ESP would skip the thermostat and communicate via the controller board/rs485 connection?
@jftaylorMn yep, that's the plan. I've put together a prototype on an esp8266 which can parse the serial stream, a command line utility to control my thermostat via rs485, and just got an esp32 box to play with getting a firmware setup so as soon as I no longer have a job or spouse or kids I'm sure I'll have enough time to get something going 😄 . All of the parts thusfar are available on amazon for a total of less than $50. If you'd like to follow the project it's here: https://github.com/nebulous/infinitesp
...as soon as I no longer have a job or spouse or kids I'm sure I'll have enough time to get something going ...
Advice from a retired empty nester... You'll be better of if you don't rush that day. A suggestion for the esp project- consider wrapping the rs485 functionality in a REST API that could be consumed by something other than a thermostat.
@nebulous I'll check in with you after the holidays. Are there instructions for installing the RS485 USB dongle and proper wiring? I assume I can just run two lead wire from the furnace to network stack...or is there a way to connect a raspberry pi as a server and allow the host to connect to it (thus isolating in the case of some unexpected electrical event lol)? Cheers!
Are there instructions for installing the RS485 USB dongle and proper wiring?
Wiring is pretty straightforward - the wiki has a page on it here
or is there a way to connect a raspberry pi as a server and allow the host to connect to it
Infinitude supports either a direct tty connection or a tcp telnet connection to a networked serial interface. The wiki page above shows my haphazard esp8266<->rs485 serial abomination. I'll see if I can refresh the wiki page since the links are likely stale by now, but most quality rs485 adaptors will be optoisolated, so there's no direct electrical pathway between the differential lines and your usb port. Many will also have a ground terminal reference which you can connect to a common ground as well. Multi drop rs485 busses really should be linear and properly terminated, though at the slow speeds (38400bps) and short runs for thermostats that doesn't end up to be really necessary in practice.
What version of Proxmox are you using? I have had the proxy working for quite some time until I recently upgraded the version of proxmox to 7.3. Now my container will use its allotted memory up to the configured high limit and then start using swap space until that is full. After which the CPU usage spikes and the proxy stops responding until restarted via the hypervisor.
I'm running 7.3-4...latest with all updates. I installed the proxy a few different ways, currently it's running via docker in a debian CT. I allocated 2GB and the CT is using 435MB, but I'm also running influxdb (which appears to be using the majority). I have fuse and nesting enabled, and unpriveleged is "no" (was thinking I'd need USB access but haven't gotten that far yet).
I am running the same version of Proxmox but I am running the application directly on the debian CT. I created a new one from the latest Debian 11 template, nesting and fuse enabled, unprivleged. The only things I did were install the dependancies and fuse-overlayfs, clone infinitude from git, and then run it. Memory usage starts at about 100MB but climbs by about .5MB every 15 seconds until it ultimately runs out of memory and swap.
I also tried running a full Debian 10 VM with infinitude installed, and it keeps growing the memory usage as well. I guess my next steps are to try it as a docker in LXC...
I think fuse was needed for docker only. In my lxc native install the settings are nesting=1, unpriv=yes, 1G ram. I just started it and looks like the perl process is only using <70mb (thermostat isn't pointing to it so it's not collecting any data). Maybe use TOP to see what process is using the memory? Is it perl? My lxc is debian 11, fully updated.
Top shows that perl is what is using the memory and the % values are what are growing over time. I have two instances running since I have two different thermostats...
OK, I went ahead and pointed the thermostat to the native install and adjusted the HA config for a full test. I started the proxy using this command:
./infinitude daemon -m production &>/dev/null &
So far after a few minutes, it's using 73 MB, seemingly holding steady. Not sure what else is left to check.
Another user reported that there may be a slow memory leak which may cause the Perl process to consume more memory over time. So you could consider a periodic restart just in case, but I’d think it would take quite a while to matter. 1G should be more than enough. I ran infinitude for years on a sbc with 256M and no swap fwiw.On Jan 7, 2023, at 5:41 PM, greggitter @.***> wrote: OK, I went ahead and pointed the thermostat to the native install and adjusted the HA config for a full test. I started the proxy using this command: ./infinitude daemon -m production &>/dev/null & So far after a few minutes, it's using 73 MB, seemingly holding steady. Not sure what else is left to check.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
Another user reported that there may be a slow memory leak which may cause the Perl process to consume more memory over time.
Not sure I would call 1MB every minute slow, I had the container set with 512/512 and it nuked itself after a few hours.
Hi,
Hoping this is an easy one and I missed something somewhere, but after searching I'm not finding anything similar. I'm getting the following error messages when trying to start the docker container using the recommended start parameters. I get the same when using the recommended command with the env variables defined. I end up having to stop the container to get my command line back via portainer.
I'm running the docker version in a Debian container on Proxmox. Any ideas on what to try for this one?
Thanks!