Take a look at some of out latest Instagram posts. We slapped one fresh out of the box on a new banger and it fit PERFECTLY. We don't even need the hooks they're just there for safety. The coils are ROCK SOLID. Our first out of the box has been going for 4 days strong around 590 degrees with no hiccups.
We switched back to our ORIGINAL (like, literally first run of HN-01, original) vendor for these (and all future coils) from now on. We've also started using Anti-Static bags for UNITS and COIL orders as an extra precaution for shipping this round. SO HANG ON TO YOUR PINK BAGS THEY'RE RAD.
The other thing about these coils (we requested this) is that they're 150w for both 110 & 220. They're more powerful than some of our previous coils. This had been reported to improve the performance of all our 220v coils significantly (so anyone waiting on an International shipment, rejoice!). We can confirm that they recover a bit quicker than the 100w coils. It may almost come down to preference for some folks...but we are very satisfied with the step up in quality these guys made over the last couple years.
They may fluctuate a tiny, tiny bit right now (ours is solid even on current tunings at HQ) because our current coil profiles are for 100w coils but we will be releasing new coil profiles for each one after we finish the bulk of R2 shipping. Just need to have results for each one run through our torture tests to plug in.
EDITS:
- Going to talk to Liz in a sec and see how she's doing on this one. (Update Below)
- A lot of 25mm coils should be going out today. If you ordered one go ahead & PM me here asap and I'll make sure you're on my list. I'm getting more labels together right now. @afeekh - Check your Inbox.
Here's a photo of one:
@ensabbahnur I forgot to mention this before. Please do test out temps and what not for the SiC Halo. I personally spent a lot of time working on that tuning and it was our daily driver for quite some time. It's in our top 3 and I think it may have the most accurate dish temp numbers at the moment. I'd love your feedback.
Please remember with our temps vs actual direct thermocouple readings: There is also a general small margin of error and potential manufacturing variations in the nails themselves. I've had dishes that were significantly different weights in term of thermal property that were supposedly 'the same'. Heat sink & lock washers can also change the thermal properties. I personally like running my Halos Low Pro with an exposed coil under the dish. Paired with SiC and still air in your dab 'zone' removing the retention washer gave me quicker recovery after larger dabs.
The other difference being that our dish temps and tunings aren't just calculated via a single (or multiple probes) DIRECTLY on the dish. We place sensors on the outside of the coil itself, outside and insides of the dish, outside and inside of the titanium center tube / screw in the case of the Halos (and more) It makes our readings on screen less accurate directly to the dish but it gives you a better idea of the temp ANYWHERE on the nail (because lets face it...it NEVER all ends up in the bottom of the dish).
Granted, this is no excuse for how off some of our current tunings are when it comes to fluctuation / dish temp and we'll fix them (but coil only mode and the previously stated steps should work well as a fix in the mean time). BUT...last I checked the SiC Halo tuning should be pretty darn close (though depending on your software version it may be different).
LIZ - RE: NETWORKING (Warning: This is complicated. Most of you won't need this.)
# WiFi Issues?
## 1. Services and Ports
The controller runs each service listed below on its own thread which is spawned from the controller daemon at startup.
The corresponding SSL Ports listed are each served through nginx as a reverse proxy providing SSL termination.
| Service | TYPE | PORT | SSL PORT |
| ---------------------- | --------- | --------- | ----------- |
| Web App HTTP Server | TCP | 8890 | 443 |
| WiFi Setup HTTP Server | TCP | 8710 | 8443 |
| Basic REST API Server | TCP | 8891 | N/A |
| MQTT Broker | TCP | 7111 | 8883 |
| UPnP-HTTP Server | TCP | 8981 | N/A |
| UPnP-SSDP Server | UDP | 1900 | N/A |
## 2. DNS Resolution / Mapping
Constructing the URLs for some of these services can be somewhat confusing.
(I'll take the blame for admittedly assigning some of the port numbers without making them make more sense...)
Each Hex-Nail has a DNS A-Record maintained for it on a Hex-Nail DNS server which maps it's friendly "rq2-0000.hn-connect.net" address to it's *LAN* IP Address.
This allows for TLS encrypted communication between the App and the controller even while on your local network.
The DNS address associated with your controller only resolves to it's address from within your LAN; it's useless/impossible to access your nail using that address from outside your LAN.
The actual remote control transport uses TLS encryption over via binary frames sent over secure websockets (wss://).
## 3. DNS, Addressing, and Ports
The WiFi Portal can be reached via:
- Unencrypted HTTP via either its Local IP address or DNS name, and basic Port:
`http://10.0.0.20:8710`
- Encrypted TLS via it's FQDN and SSL Port:
`https://rq2-0000.hn-connect.net:8443`
Similarly the WebApp instance hosted on your Hex-Nail itself can be reached via:
- Unencrypted HTTP via either its Local IP address or DNS name, and basic Port:
`http://10.0.0.20:8710`
`http://rq2-0000.hn-connect.net:8710`
- Encrypted TLS via it's FQDN and SSL Port:
`https://rq2-0000.hn-connect.net:8443`
**The trick here is that SSL certificates are almost exclusively bound to a hosts' DNS name (matching the cert's "Common Name" (CN)), and thus don't work with URLs using IP addresses as hostnames.**
This is an odd example of where security on the internet is somewhat inherently hindered by design, at least when it comes to using a web-based application or service over a secure transport to connect or control other devices on your local network.
## 4. WiFI Portal HTTP Server and JSON API
The WiFi Setup Portal we direct you to during initial setup is a separate HTTP Server with a few endpoints, all on port 8710 (HTTP) or 8443 (HTTPS):
- GET: / = Static HTTP file server service the WiFi setup portal html, and static assets.
- GET|POST: /wifi = JSON API Endpoint used by the WiFi setup form:
- GET will give you a list of networks
- POST to save/connect to a WiFi network with a json payload:
{ "ssid": "...", "passphrase": "..." }
- GET|POST: /wifi-advanced = JSON API for loading and saving the configuration under the Advanced
WiFi Section
- GET: /wifi-status = Provides basic WiFi status as json (ip_address, associated, ssid)
- GET: /system = Crude dump of system status and log output, usually throws a 500
- GET: /status = Returns the JSON representation of the global controller state object.
To manually issue a WiFi Connection request to your Hex-Nail, send a HTTP POST and JSON payload to:
http://<ip-address>:8710/wifi
{ "ssid": "...", "passphrase": "..." }
_There will be a more comprehensive WiFi Connection Manger exposed through the App itself in an upcoming update._
## 5. Minimal Control Interface
The API running on TCP 8891 exposes just four URLs used as an adapter interface for extremely simple remote control/integration:
- GET /heater/heater_on
- GET /heater/heater_off
- GET /system/hardware_version
- GET /system/device_id
An MQTT Message Broker runs on TCP 7111 and handles all of the JSON messages and streaming binary websocket frames sent between the controller and the App.
## 6. Device & Service Discovery
There's a UPnP+SSDP+HTTP service discovery system running such that:
- SSDP service advertisements and search requests are sent via HTTP Multicast on UDP 1900 to 239.255.255.250.
- Search responses are sent by the controller service on the same UDP 1900 but using Unicast, providing the client with a URL to then request from the UPnP-HTTP server running on TCP 8981, providing them an XML descriptor.
- The native mobile apps will make better use of this stack to more quickly and reliable connect to your Hex-Nail.
EDIT: @nickmo - You're going to love the banger tuning. I promise. It's my pride and joy so far. Used 3 different brands of bangers with it and it's pretty solid. It was originally made for the Eternal Quartz banger.## 1. Services and Ports
The controller runs each service listed below on its own thread which is spawned from the controller daemon at startup.
The corresponding SSL Ports listed are each served through nginx as a reverse proxy providing SSL termination.
| Service | TYPE | PORT | SSL PORT |
| ---------------------- | --------- | --------- | ----------- |
| Web App HTTP Server | TCP | 8890 | 443 |
| WiFi Setup HTTP Server | TCP | 8710 | 8443 |
| Basic REST API Server | TCP | 8891 | N/A |
| MQTT Broker | TCP | 7111 | 8883 |
| UPnP-HTTP Server | TCP | 8981 | N/A |
| UPnP-SSDP Server | UDP | 1900 | N/A |
## 2. DNS Resolution / Mapping
Constructing the URLs for some of these services can be somewhat confusing.
(I'll take the blame for admittedly assigning some of the port numbers without making them make more sense...)
Each Hex-Nail has a DNS A-Record maintained for it on a Hex-Nail DNS server which maps it's friendly "rq2-0000.hn-connect.net" address to it's *LAN* IP Address.
This allows for TLS encrypted communication between the App and the controller even while on your local network.
The DNS address associated with your controller only resolves to it's address from within your LAN; it's useless/impossible to access your nail using that address from outside your LAN.
The actual remote control transport uses TLS encryption over via binary frames sent over secure websockets (wss://).
## 3. DNS, Addressing, and Ports
The WiFi Portal can be reached via:
- Unencrypted HTTP via either its Local IP address or DNS name, and basic Port:
`http://10.0.0.20:8710`
- Encrypted TLS via it's FQDN and SSL Port:
`https://rq2-0000.hn-connect.net:8443`
Similarly the WebApp instance hosted on your Hex-Nail itself can be reached via:
- Unencrypted HTTP via either its Local IP address or DNS name, and basic Port:
`http://10.0.0.20:8710`
`http://rq2-0000.hn-connect.net:8710`
- Encrypted TLS via it's FQDN and SSL Port:
`https://rq2-0000.hn-connect.net:8443`
**The trick here is that SSL certificates are almost exclusively bound to a hosts' DNS name (matching the cert's "Common Name" (CN)), and thus don't work with URLs using IP addresses as hostnames.**
This is an odd example of where security on the internet is somewhat inherently hindered by design, at least when it comes to using a web-based application or service over a secure transport to connect or control other devices on your local network.
## 4. WiFI Portal HTTP Server and JSON API
The WiFi Setup Portal we direct you to during initial setup is a separate HTTP Server with a few endpoints, all on port 8710 (HTTP) or 8443 (HTTPS):
- GET: / = Static HTTP file server service the WiFi setup portal html, and static assets.
- GET|POST: /wifi = JSON API Endpoint used by the WiFi setup form:
- GET will give you a list of networks
- POST to save/connect to a WiFi network with a json payload:
{ "ssid": "...", "passphrase": "..." }
- GET|POST: /wifi-advanced = JSON API for loading and saving the configuration under the Advanced
WiFi Section
- GET: /wifi-status = Provides basic WiFi status as json (ip_address, associated, ssid)
- GET: /system = Crude dump of system status and log output, usually throws a 500
- GET: /status = Returns the JSON representation of the global controller state object.
To manually issue a WiFi Connection request to your Hex-Nail, send a HTTP POST and JSON payload to:
http://<ip-address>:8710/wifi
{ "ssid": "...", "passphrase": "..." }
_There will be a more comprehensive WiFi Connection Manger exposed through the App itself in an upcoming update._
## 5. Minimal Control Interface
The API running on TCP 8891 exposes just four URLs used as an adapter interface for extremely simple remote control/integration:
- GET /heater/heater_on
- GET /heater/heater_off
- GET /system/hardware_version
- GET /system/device_id
An MQTT Message Broker runs on TCP 7111 and handles all of the JSON messages and streaming binary websocket frames sent between the controller and the App.
## 6. Device & Service Discovery
There's a UPnP+SSDP+HTTP service discovery system running such that:
- SSDP service advertisements and search requests are sent via HTTP Multicast on UDP 1900 to 239.255.255.250.
- Search responses are sent by the controller service on the same UDP 1900 but using Unicast, providing the client with a URL to then request from the UPnP-HTTP server running on TCP 8981, providing them an XML descriptor.
- The native mobile apps will make better use of this stack to more quickly and reliable connect to your Hex-Nail.
Last edited:
I originally moved to Cali to be a Budtender but after applying to 200+ places between the Bay and LA I just gave up on being a part of what I loved until we started doing this. Had to force our way in if we wanted into the weed game. lol
