i10D personality module not identified correctly

[george-basco]

Describe the bug I have an Intellicenter with the i10D (523029Z) module. It is incorrectly being identified as a 522039 cover module. The system is being identified as an i5P.

Expected behavior initExpansionModules is being called with: ocp0A=0x87, ocp0B=0, ocp1A=0, ocp2A=0, ocp3A=0

The slot1 valve expansion board gets identified correctly. slot0 (value of 7) should be identified as i10D but is not.

I changed the code in IntellicenterBoard.ts so that a value of 7 identifies the i10D expansion board. And also changed the line: if (pb.type === 0 || pb.type > 5) that identifies the system as i5P to: if (pb.type === 0 || pb.type > 7)

I then get correct identification in poolConfig.json, but the rest of the config isn't being filled out, e.g. circuits. I'm looking at this code for the first time, so don't understand at all what's going on.

Let me know what information would be helpful. Thanks..

Pool Equipment

• Controller: Intellicenter
• Controller Model: IntelliCenter i10D
• Controller Firmware Version: 1.045
• Pump(s) manufacturer and model: IntelliFlow 022056
• Valves: Intellivalve

[george-basco]

replay (6).zip

[tagyoureit]

@rstrouse can you take a look?

[rstrouse]

Ahah, we finally see the signatures for i10D. I have modified the code to see your signature. This has been published to next. The dual equipment configuration is new so let me know if there are any other issues. The place to look is with the valve and heater attachments. There was a change with 1.047 beta to the heat sources and heat modes so let me know if these are not correct in 1.045. The official release is still 1.040 and I don't know what Pentair did with these in 1.045. It's starting to look like there are more people running unofficial releases than official ones.

BTW: These changes have been posted into the Next repository.

[george-basco]

I had already tried the change you made. Also need to change this line:

https://github.com/tagyoureit/nodejs-poolController/blob/f11816b9c666e6417da34014d301339cfa5d85f5/controller/boards/IntelliCenterBoard.ts#L296

Those changes did identify the i10D correctly, but didn't do anything to identify pumps, valves, circuits, etc. Currently none of those things are getting filled in. If you look at the zip file above you'll see most things are empty. To start with there are two pumps and 6 valves attached that aren't showing up anywhere. Not sure where to start..

[rstrouse]

Oh yes there is a some goofiness with the i5p as this has no board installed in slot 0 but it reports garbage in the MSB of the lower nibble. I think that only the first 3 bits are defined for the slot. The other equipment should be detected as soon as the correct board signature is detected. I assume that you get a total of 10 valves for i10D + valve expansion. Is there a valve dedicated for each body or how does that work since there is no intake/return thingy going on? I posted up changes to drop that bit from the slot0 i5P detection.

Once the software starts you will see the njspc start to ask for the configuration items. It only asks for the items that it needs and since the definition didn't include all the equipment counts from the signature it didn't ask IntelliCenter for the equipment defintitions. You should see a line that looks says something like Queued 70+ Configuration items for your configuration at startup. After it acquires all the equipment it will only ask for the things that have changed since the last time it asked. That is what the configVersion section is all about in the poolConfig.json.

[rstrouse]

Once it detects the i10D correctly do another capture as your packetLog shows the OCP not responding to action 228. The OCP is supposed to respond with the versions of currently installed equipment. This is perhaps because the requesting address was not properly being set because of the lack of personality board being found.

[george-basco]

i10D now correctly gets identified, but still no response for action 228. Here are the logs:

replay (8).zip

[rstrouse]

It sounds like you are pretty technically adept. I have some questions and I am confident that we can figure this out. It is odd that it is not responding to 228. However, this is not to say that they didn't change something between 1.040 and 1.045 that might make a difference here. If you have installed dashPanel I would like you to load up the messageManager that is included in this package. It can be opened by typing http://<ipaddress of dashPanel server>/messageManager.html Bear in mind these are the tools that we use to inspect the RS485 bus and haven't spent too much time documenting them. In the end I want to see what is communicated on this bus from other slave controllers.

What this software does is monitor the RS485 bus traffic. The screenshot is a picture of your log you sent me. From this log I see that the bus is healthy but the OCP is just not responding to the 228 action -- "Request for Equipment Versions." This log also tells me that njspc is correctly now awaiting responses from the panel on what to do next. I can see the OCP taking control of 3 pumps on the bus and sending information related to the temperature sensors, circuit states, and other operations.

The typical response to 228 is action 164 which lets njspc know what equipment is installed on the controller. Do you have an indoor controller or a wireless controller connected to the RS485 bus. If you do there are tells from these controllers. It could be as simple as finding the correct request source for the message. We can find this by observing what the other controllers on the bus are asking for and how they are asking for it. Once you get the messageManager up and running go to the next post for further instructions.

[rstrouse]

Your mission, should you choose to take it is to infiltrate the RS485 communications, retrieve the secret discussion taking place under our nose and report back here. Unfortunately, this is where the drama ends and this message won't self destruct.

Anyhow, once installed, click the upper right corner where the menu bars are located. This will open a panel that contains the connection and the logging options for the messageManager. If the screen is showing "Not Connected' then we need to set the ip address for njspc into the connections tab. Once we are connected, click on the logging tab. From there I would like to filter out some of the messages that are coming in so we don't get so much noise. We are only interested in broadcast messages so click the Packets button, File button, and the Broadcast button. Everything else is just noise at this point. Your filter should look like the screenshot.

Once you have this set up you can start observing the messages on the RS485 bus. It would be spectacular to see a 228 message that wasn't sent by njspc, but if we don't that's ok. Click the last button on the top of the messages list (make it pink) to begin receiving messages on the bus. You should start seeing action 2 and 204 being sent at regular intervals. Then wake up an indoor control panel (if you have one). If you don't then use the web or mobile app and change a configuration setting. Simply changing the name of a feature will suffice. Once you have done that you can go back to the Logging tab and uncheck Log to -- File button. This will stop writing messages to the file. Please remember to do this as that file can grow out of control if you let it. You can also unclick the message feed on the messages list.

A log file will be written to the njspc logs directory. Please upload that log here. It will be timestamped with the date and time that the first message was logged.

[george-basco]

Might be doing something wrong, but not getting anything very interesting by changing a circuit name. Just see a 168 action. Here are some various scenarios I captured.

rename a circuit twice on the IOS app: ios-app-rename.log

rename a circuit twice on intellicenter.com web interface: web-rename.log

wakeup ICP and rename circuit twice: icp-rename.log

Power cycle the ICP: icp-power-cycle.log

Reboot the OCP: ocp-reboot.log

Haven't really looked at them in any detail, but I think only the last two have any interesting data.

Let me know if there are any other scenarios that would be helpful to capture. Thanks for looking at this. This Pentair stuff is completely new to me, so clueless on what any of this means.

[rstrouse]

Well, look at that. It is communicating on address 32. Hmmm, add the pluginAddress line to your config.json file for njspc under the controller section. Then restart njspc. Let's see if the i10D recognizes the address.

"controller": {
   "pluginAddress": 32,
   "comms": { ...

Also, with the message feed turned on and the following filter set up by clicking on the filter icon in the Broadcast button let's send the i10D a request.

Step 1

On the "Send Message Queue" section of the messageManager click on add message and enter the information as you see it on this screen. Then press the Save Message Button.

Step 2

After you press the save message you should see the new message added to the queue on the Send Message Queue section. Turn on the message feed by making the top right Message List icon pink. Then press the Send Queue button. Since we have all the other messages filtered out we should only see the ones we are interested in.

Step 3

The expectation is to see a 228 get sent followed immediately by a 164 message. If the 164 comes back it will trigger njspc to start asking for information from the ocp if it doesn't have it.

[george-basco]

Pretty sure I did this correctly. There is no response from the OCP to the 128 request. Nothing but the 2/204 chatter.

[rstrouse]

Yes you did this correctly. Hmmm, change the controller byte from 63 to 1 and try it again. You can do this by clicking the little edit icon next to the message in the queue. Then send it again. If this is true 1.045, changed the controller byte and the source byte. It will be interesting if they did it per platform, either way it will be a short task to fixing it once we know what that is.

[george-basco]

Changing controller from 63 to 1 had no effect. I'll go back to 1.040 and see what happens with that..

[rstrouse]

Will it even let you go back to 1.040 from the 1.045 beta? Here is something interesting. Below was from your reboot-icp.log. Is this rebooting an Indoor Control Panel? It actually succeeded on the reboot of the control panel in sending back a 164.

Try sending this message to see if we get anything back. Note the destination is 16 not 15. Hit send queue a few times just in case we have a collision.

[george-basco]

Looks like you can install whatever version of firmware you'd like. I went back to 1.040. However, nothing has changed. Seems like everything from njspc is ignored.

The icp-power-cycle.log file is the case of power cycling the indoor control panel. If I copy the packet you highlight above and replay it nothing happens. Btw, going back to 1.040 firmware, I still see the same 228 request go out when the ICP power cycles. Haven't noticed any differences in the packets between 1.045 and 1.040.

Then I tried replaying 168 actions for a circuit rename from the IOS app. Again, it seems to get ignored and the name is not changed.

I was stating to think there is something wrong with the RS-485 output from the rpi. But after looping it back, seems like it's working OK. And certainly the reading of the bus looks fine. I haven't captured njspc initiated packets, but simple echo test was good.

Again, seems like everything from njspc is simply ignored, even those packets that are copied and replayed from things like the ICP. Maybe you have other suggestions on tests that would show the njspc packets are making it to the wire.

The dashPanel interface did manage to populate for the first time when I downgraded the firmware on the OCP and it booted. And the data looked mostly complete. However, if I tried to do anything on dashPanel, all actions failed after retrying the command 4 times.

[george-basco]

One question I forgot to ask in the previous post is whether you've seen any evidence that something has responded to a packet from njspc in the various logs of mine that you've looked at?

[rstrouse]

I have seen no evidence of the OCP responding to any request from njspc. It's odd in that you even sent it the exact stream of bytes that were sent from the ICP and nada. Perhaps there is some issue with the RS485 dongle. It is odd that it would read but not write. Interestingly, njspc is not particular about which controller asked for the configuration so it probably scraped the data from the ICP asking for it which is how it picked up the configuration. This has to be a connection problem either with the dongle or the wiring.

Give me a bit of background on what platform you are on and which dongle you are using. I have had a dongle go stupid after being connected to socat but I suspect this is due to the fact that node serial port doesn't reset all the registers. I had to force a settings reset it through a PC. In that case it was acting like it was full duplex (don't even know how that is on RS485 unless there are 2 pairs) but the other way around where it would write but not read. The weird part was that the dongle only supported half duplex anyway. In this instance you should only have 2 wires connected up to the dongle.

[george-basco]

I have this dongle based on the CP2102 chip: https://smile.amazon.com/gp/product/B078W5L8W1/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Have just the TxD and RxD pins connected to the OCP main board along with the pumps. The dongle is connected to a rpi 4b running Raspbian GNU/Linux 10 (buster). Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l GNU/Linux.

Was wondering if there was something not quite right with the tty settings, but looks like the interesting tty options are configured in the serial configuration code. Suppose I should have something else snoop the RS485 to look for the njspc output. Probably should just order one of the dongles that is more of a known quantity, I ordered mine before doing much research.

[rstrouse]

I couldn't see anything in there about supporting RS485 half duplex. It states that it supports TTL but no discussion about putting it into RS485 mode. RS485 is different than TTL but I have seen some TTL adapters that can be coerced int o looking at differential voltage rather than TTL which is just on/off. Our output on TTL will end up in a bucket of bits on some unknown island if we encode it on the wire as non-differential voltage which appears to be happening.

Here is the adapter I have. It's cheap and it works. https://www.amazon.com/JBtek-Converter-Adapter-ch340T-Supported/dp/B00NKAJGZM/ref=sr_1_8?dchild=1&keywords=rs485+usb&qid=1599353709&s=electronics&sr=1-8

[george-basco]

Oh, I'm an idiot. Really sorry for wasting your time on this. Just ordered a proper adapter...

[rstrouse]

No worries. We did manage to figure out a mystery that we had regarding the i10D signature. I'm excited to see if we made all our assumptions about that board correctly.

[george-basco]

Things work much better when you know how to speak RS-485 :-) Thanks for helping me sort that out.

At first glance most things look correct and I'm able to control things as expected. The one issue I do see is with the valves. I forgot to answer your earlier question about valves. The i10D only has two valves A & B. With the valve expansion board (6 valves) I have a total of 8. It also appears that the non-shared personalities all have the two valves. This include i5P, i8P, i10P and i10D. You can see this on page 61: https://www.pentair.com/content/dam/extranet/pentair-pool/residential/manuals/automation/intellicenter/intellicenter-automation-system-installation-guide.pdf

Looks like the code in controller/comms/messages/config/ValveMessage.ts will need to be reworked given the lack of inake/return valves. The current code results in the following dashPanel display for valves:

vs. what it looks like from intellicenter.com:

Here are the logs: replay.zip

[rstrouse]

Glad to see you deciphered the babel. I didn't realize you could read RS485 with a TTL but that does make sense.

Valves are odd and now that you are here we now know that it does not include either of the intake/return valves in the valve count. I'll make the mods to the code. This also means that there is no fancy code for body management unless the water is shared between the two. Unfortunately, this also leaves the second Intake/Return slot unaccounted for, We had assumed that Pentair gave you one or the other but I guess the relay to activate it would have to be on the personality board anyway.

I'll fix this this week and post back here when the code is up. Let me know if there are any other anomalies.

[rstrouse]

Alright this week is here. I posted the fixes for the i10D. Consequently, your configuration solved some mysteries with the valves but created others. There are 2 valve positions in the midst of the configuration that are unaccounted for in position 5 and 6 no matter what might be installed.

Funny, we do have people running single body systems but they haven't reported two extra valves that don't do anything. Clearly there are no additional valve connections on the P models like there are on the PS. The same can be said with the X models.

The claim is that there are 26 supportable valves. However when I add them up I come up with 28 if these two ghost positions are included. If you remove them from the count, then the numbers come out correct for 3 expansion panels and 4 valve expansions. Given the current number of installable boards you can count to 26 physical connections and the position 5 and 6 can never be used.

Anyhow, once you install the update, go to the hamburger menu. On the system tab, click the "Reload Config" button an this will interrogate the panel again. The percentage bounces around as njspc detects new equipment to ask for, but once it is done, your valve installations should be correct. Let me know if there are any other discrepancies.

I did notice something odd about your timezones. While IntelliCenter has the correct timezone, I suspect the computer that is running the njspc server does not. If it is a pi these come set to GMT by default with DST turned on. The DST setting is correct but you may see some weirdness with the time in njspc as we try to localize it with IntelliCenter.

[george-basco]

Last two valves are missing names:

Reloaded multiple times, but names always missing.

replay (10).zip

Timezones should match now..

[rstrouse]

Ahah, you two gaps in the names. This means that it needed to ask for 2 more names. I have modified the code to ask for these two as well.

[george-basco]

Valves all look great now. Thanks!

I've noticed another issue, which btw doesn't seem important to my setup, with feature circuit type. All of my feature circuits are of type generic. However, njspc shows them all as type spillway.

If I change the type in any of the interfaces, njspc tracks the type correctly. However, njspc seems to not correctly determine their type at startup/reload config, always showing them as type spillway.

I don't know what spillway type even means, but pointing it out in case it's meaningful to others..

[george-basco]

Btw, looking at that last screenshot reminded me that the 24h0m egg timer is misleading. It's a dashPanel issue, but that should be displayed as "don't stop"

[rstrouse]

That's funny. I'm guessing that the type is not relevant to an i10D as spillway is a feature the rotates the Intake and Return such that water spills out of the spa and into the pool. I'll have a look at the action 30 [5, ...] message.

I also agree with the don't stop it just comes from the OCP as 24. We'll translate that into don't stop. They use a checkbox on the IntelliCenter app but it really is 24 in the hours byte of teh egg timer.

[rstrouse]

If you pull both njspc and dashPanel the don't stop function now works and the feature type also works. You will need to reload config to see the changes.

What options do you see in the IntelliCenter web for feature circuit types? I see two Generic and Spillway. Is your list different?

[george-basco]

All looks and works great! I see the same list of circuit types as you. Thanks..

[rstrouse]

Strange. Spillway would only make sense in a shared body system.

[george-basco]

Found a problem with light groups. Not sure if this is related to the dontstop changes or not. If I try to do anything to a light group in dashPanel, njspc dies. E.g. if I edit the name of the group:

[9/10/2020, 15:51:14] info: [15:51:14] 192.168.1.28 GET /config/options/lightGroups?null {} [9/10/2020, 15:51:26] info: [15:51:26] 192.168.1.28 PUT /config/lightGroup {"id":200,"type":1,"name":"All","dontStop":false,"circuits":[{"circuit":3,"color":0,"swimDelay":0,"position":1},{"circuit":4,"color":0,"swimDelay":0,"position":2}],"eggTimer":720} [9/10/2020, 15:51:26] info: {"id":107,"valid":true,"dir":"out","proto":"broadcast","pkt":[[],[255,0,255],[165,1,15,33,168,40],[6,0,7,1,1,0,2,3,255,255,255,255,255,255,255,255,255,255,255,255,255,255,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,12,0],[15,184]],"ts":"2020-09-10T15:51:26.686-0700"}

/home/pi/src/nodejs-poolController/nodejs-poolController-next/controller/boards/IntelliCenterBoard.ts:1466 sgroup.eggTimer = group.eggTimer = eggTimer; ^ TypeError: Cannot set property 'eggTimer' of null at Outbound.onComplete (/home/pi/src/nodejs-poolController/nodejs-poolController-next/controller/boards/IntelliCenterBoard.ts:1466:44) at SendRecieveBuffer.clearResponses (/home/pi/src/nodejs-poolController/nodejs-poolController-next/controller/comms/Comms.ts:343:73) at SendRecieveBuffer.processInbound (/home/pi/src/nodejs-poolController/nodejs-poolController-next/controller/comms/Comms.ts:404:37) at SendRecieveBuffer.processPackets (/home/pi/src/nodejs-poolController/nodejs-poolController-next/controller/comms/Comms.ts:219:21) at Timeout._onTimeout (/home/pi/src/nodejs-poolController/nodejs-poolController-next/controller/comms/Comms.ts:192:109) at listOnTimeout (internal/timers.js:549:17) at processTimers (internal/timers.js:492:7)

[rstrouse]

Pull on njspc. This was always lurking but the don't stop code exposed it.

[rstrouse]

Hey, am I reading this correctly? Do you have an A/D Cover module installed?

[george-basco]

I have a pool cover and was planning to get the cover module. I played around with the cover config stuff to see what's possible. After realizing how limited the latest state of the art Pentair programming model is, I started down the RPi path. So unlikely to get the module at this point and just use the RPi for what I need.

The light group crash is fixed, but I'm still seeing some strangeness with creating/editing light groups. I think it mostly comes down to the njspc's cached state being out of sync. Nothing critical, but I like to document any anomalies.

Here's an example using dashPanel:

1. create a new light group named All
2. add two light circuits

3. save the group

4. Notice the egg timer shows 0h 12m after the save happens
5. Look at poolConfig.json:

   {
     "id": 200,
     "type": 1,
     "circuits": [
       {
         "id": 1,
         "circuit": 3,
         "swimDelay": 0,
         "color": 0
       },
       {
         "id": 2,
         "circuit": 4,
         "swimDelay": 0,
         "color": 0
       }
     ],
     "name": "All"
   }
   ],

6. Notice no value for eggTimer. Requires a Reload Config to get things in sync. After the reload, poolConfig.json now has:

  "lightGroups": [
    {
      "id": 200,
      "type": 1,
      "circuits": [
        {
          "id": 1,
          "circuit": 3,
          "swimDelay": 0,
          "color": 0
        },
        {
          "id": 2,
          "circuit": 4,
          "swimDelay": 0,
          "color": 0
        }
      ],
      "name": "All",
      "isActive": true,
      "lightingTheme": 0,
      "eggTimer": 720,
      "dontStop": false
    }
  ],

And dashPanel now shows the expected values:

[rstrouse]

Ah, that explains the empty slot. I thought were were missing a byte somewhere. I'll have a look at the light group settings. Your definition was actually missing several other properties.

You can load the relay equipment manager to control a relay. It does directly connect to the websocket for njspc as a trigger for the the relay to control the cover. Do you know how the cover functionality is supposed to work? Does it disable the listed circuits so that they won't do anything if the cover is closed or does it open the cover then start the circuit?

[george-basco]

I don't really know how the cover module works. There doesn't appear to be much of any documentation for it. My guess from the interllicenter.com interface is that you can disable circuits in either open/closed state. Don't think they would support automating the opening/closing of the cover.

One other comment about lights since we;re on the topic, although this would be a dashPanel thing. I think the various Pentair interfaces (intellicenter.com, IOS app, OCP) all automatically display any light circuits in a "Lights" UI and provide an all on/off button. This happens without creating any light groups. Given dashPanel has a LIghts panel on the home screen, might make sense to do the same there. Not really needed of course, the lights show up in the Features panel and you can of course create a light group for the all on/off functionality. But just a thought considering the Pentair interfaces all seem to do something like this. Although as I type this I realize that's probably reason to not do it :-)

[theRealMCQwerty]

Re: cover module. I have the cover module but haven't installed it yet. It has two dry contact inputs on it, (2 because it supports up to 2 covers), My understanding of the functionality is the same as @george-basco that "on cover closed detected, set valve(s) x,y,z to open/closed".

[rstrouse]

Yeah that does seem odd to me though given the architecture. I assume that the circuit list is somehow disabled so when it gets a request that request is ignored. There must be some sort of response from the OCP that says it got the request but rejected it. The constructs obviously don't exist without the module. Otherwise the controller would try multiple times on each failure.

Btw the group initialization method has been fixed. The funny part was that it wasn't happening to me because I have many controllers (including 2 njspcs) on the same bus. These were adept enough to ask for information they didn't have so that communication initialized the egg timer. Anyhow, it is fixed and thanks for the detailed description.

On the all on/off I have plans on adding it but just haven't figured out what the widgetry will look like. I have gone back and forth with adding it to the header but there are other things that appear there on Touch systems for IntelliBrite. Most notably, in Touch these items are promoted to the header because you cannot control the light circuits individually.

There is one thing to note about lights and "Show In Features." They are odd, while you can create features and circuits that do not appear on the interface, you cannot create lights that do not show on the interface. With lights, the Show In Features checkbox determines whether it shows up in the features list or on the lights list. This is because some of the IntelliBrite based control elements are both lighting and feature. This includes the lighted water feature equipment like MagicStream and the bubblers.

[george-basco]

Looks great! Now for the truly nitpicky. Spacing for "Don't Stop" needs adjustment just for the light groups. The other circuit types all look fine:

[rstrouse]

Hmm... do a hard refresh of your browser. Sometimes the css cache isn't cleared on change. I'll add a couple of rems to the header width to handle the variance and force the text to a single line.

[rstrouse]

Alright I pushed the change so it cannot wrap and gave it a bit more space.

[george-basco]

The latest code definitely fixes the issue. Thanks!

[theRealMCQwerty]

There is one thing to note about lights and "Show In Features." They are odd, while you can create features and circuits that do not appear on the interface, you cannot create lights that do not show on the interface. With lights, the Show In Features checkbox determines whether it shows up in the features list or on the lights list. This is because some of the IntelliBrite based control elements are both lighting and feature. This includes the lighted water feature equipment like MagicStream and the bubblers.

@rstrouse I have a bubbler so I decided to try this. I checked the 'show as feature' box on the circuit that controls the bubbler light transformer. It now shows a single toggle button in the features AND the bubbler light control shows in the 'lights' section. I suppose this is as I expected but I don't see the point. I get your comment that a bubbler is a feature as well as a light but the 'feature' part of it is really the valve that controls the flow of water to it. What is the point in having a on/off switch on the features section when the full light controls are only in the 'lights' section? Additionally, I can do this for any light circuit (designate it as a feature that is) not just one of the magicstream type items. Just trying to unpack your comment a bit and understand what you meant....

[george-basco]

This is a dashPanel thing (looks like njspc has all the right data), but related to multiple bodies, so posting here. Under the heaters config, the body name is not displayed correctly. In this case "Body 1" should be Pool and "Body 2" should be Spa.

[rstrouse]

Yeah this is showing the un-mapped value. We weren't sure which order it all came in with a dual body system. Out of curiosity do you have a manual heat setting on both bodies or does it exist only on the second body? You will see this in the OCP bodies page.

[george-basco]

They both have manual heat setting:

[rstrouse]

Nope that is not what I mean. Manual heat is a goofy name for when I turn on that body manually. the heater automatically gets set to the gas heater. You will find this setting on the bodies configuration.