Technical Support FAQ

Technical questions and detailed troubleshooting information.

Network & Connectivity

Q: What WiFi standards are supported?

A: Supported:

802.11 b/g/n (2.4 GHz)
WPA2-PSK encryption
DHCP and static IP

Not supported:

5 GHz networks
WPA3 (limited support, depends on router)
Enterprise WiFi (802.1X)
Captive portals (hotel WiFi)

Q: Can I use a WiFi extender?

A: Yes, but ensure:

Extender broadcasts 2.4 GHz network
Same SSID as main network (seamless roaming)
Good signal strength at device location
No isolation mode enabled

Q: How do I set up static IP?

A: Two methods:

Option 1: DHCP Reservation (recommended)

Find device MAC address
Create reservation in router
Device gets same IP every time

Option 2: Device Static IP

Settings → Network → WiFi
Network Mode: Static IP
IP Address: 192.168.1.100
Subnet: 255.255.255.0
Gateway: 192.168.1.1
DNS: 8.8.8.8

Q: Device keeps getting different IP addresses

A: Solutions:

Set DHCP reservation in router
Use device hostname: motorwala-01.local
Configure static IP on device
Update automation platform with new IP

Q: Can devices work on separate VLANs?

A: Yes, with proper routing:

Devices on VLAN 20 (IoT)
Home Assistant on VLAN 10 (trusted)
Router allows VLAN 10 → 20 traffic
Firewall rules permit required ports

Ports needed:

HTTP: 80
MQTT: 1883
mDNS: 5353 (for .local addresses)

Q: WiFi signal strength requirements?

A: Minimum requirements:

RSSI: Better than -75 dBm
Quality: >30%
Packet loss: <5%

Check signal:

curl http://192.168.1.100/api/system/wifi

Recommendations:

-50 dBm or better: Excellent
-50 to -60 dBm: Good
-60 to -70 dBm: Fair (workable)
-70 to -80 dBm: Poor (consider extender)
Below -80 dBm: Unusable

MQTT Configuration

Q: Do I need an MQTT broker?

A: Not required, but recommended:

Without MQTT:

HTTP API only
Polling required for state
No real-time updates
More network traffic

With MQTT:

Real-time updates
Efficient pub/sub
Better HA integration
Lower latency

Q: Which MQTT broker should I use?

A: Recommendations:

Mosquitto (most popular):

# Install on Raspberry Pi/Linux
sudo apt-get install mosquitto mosquitto-clients

# Or use Home Assistant's built-in MQTT broker

EMQX (enterprise):

Better for >100 devices
Web dashboard
More features

HiveMQ (cloud option):

Managed service
Good for testing

Q: MQTT QoS - which level to use?

A: Recommended settings:

Commands (to device):

QoS 1 (at least once)
Ensures delivery
Slight overhead

State updates (from device):

QoS 0 (at most once)
Fastest
Minor loss acceptable

Critical events:

QoS 2 (exactly once)
Slowest but guaranteed
Rarely needed

Q: MQTT connection keeps dropping

A: Common causes:

1. Keep-alive too short:

# Device settings
MQTT Keep Alive: 60 seconds

2. Broker limits:

# mosquitto.conf
max_connections 100
max_queued_messages 1000

3. Network issues:

Check WiFi stability
Monitor broker logs
Test with mosquitto_sub

4. Persistent session issues:

# Try clean session
MQTT Clean Session: Yes

Q: How do I secure MQTT?

A: Security layers:

Level 1: Username/Password

# Create Mosquitto password
sudo mosquitto_passwd -c /etc/mosquitto/passwd wala-devices

Level 2: TLS Encryption

# mosquitto.conf
listener 8883
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/server.crt
keyfile /etc/mosquitto/server.key

Level 3: Client Certificates

Each device has unique cert
Strongest security
Complex setup

Level 4: Network Isolation

VLAN for MQTT devices
Firewall rules

Q: MQTT topic naming best practices?

A: Recommended structure:

Pattern:

[device-type]/[location]/[device-id]/[attribute]

Examples:

motorwala/living-room/01/position
motorwala/living-room/01/state
motorwala/bedroom/02/position
relaywala/garage/01/relay/1/state

Benefits:

Easy to understand
Wildcard subscribing
Logical grouping
Scalable

Wildcards:

# All MotorWala devices
motorwala/#

# All living room devices
*/living-room/#

# All positions
*/*/*/position

API & Integration

Q: API rate limits?

A: Default limits:

HTTP API:

100 requests per minute per IP
Burst: 20 requests
429 error if exceeded

MQTT:

10 messages per second
No hard burst limit

WebSocket:

No specific limit
Connection limit: 4 simultaneous

Limits sufficient for normal use. Contact for enterprise needs.

Q: How do I handle API errors?

A: Best practices:

1. Implement retries:

import requests
from tenacity import retry, stop_after_attempt, wait_fixed

@retry(stop=stop_after_attempt(3), wait=wait_fixed(2))
def control_motor(action):
    response = requests.post(
        f'http://192.168.1.100/api/motor/{action}',
        timeout=5
    )
    response.raise_for_status()
    return response.json()

2. Check response codes:

if response.status_code == 200:
    # Success
elif response.status_code == 401:
    # Auth failure - check token
elif response.status_code == 429:
    # Rate limited - back off
elif response.status_code >= 500:
    # Server error - retry

3. Timeout handling:

try:
    response = requests.post(url, timeout=5)
except requests.Timeout:
    # Handle timeout
except requests.ConnectionError:
    # Device offline

Q: WebSocket connection keeps closing?

A: Common issues:

1. Inactivity timeout:

// Send periodic ping
setInterval(() => {
  if (ws.readyState === WebSocket.OPEN) {
    ws.send(JSON.stringify({ type: 'ping' }));
  }
}, 30000);

2. Implement reconnection:

function connect() {
  const ws = new WebSocket('ws://192.168.1.100/ws');

  ws.onclose = () => {
    setTimeout(connect, 5000); // Reconnect after 5s
  };

  ws.onerror = (error) => {
    console.error('WebSocket error:', error);
    ws.close();
  };
}

3. Check device limits:

Max 4 simultaneous WebSocket connections
Close unused connections

Q: How do I authenticate API requests?

A: Include Bearer token:

curl:

curl -H "Authorization: Bearer ww_your_token_here" \
  http://192.168.1.100/api/status

Python:

headers = {
    'Authorization': 'Bearer ww_your_token_here'
}
response = requests.get(
    'http://192.168.1.100/api/status',
    headers=headers
)

Node.js:

const headers = {
  'Authorization': 'Bearer ww_your_token_here'
};
const response = await axios.get(
  'http://192.168.1.100/api/status',
  { headers }
);

Home Assistant:

rest_command:
  open_blinds:
    url: "http://192.168.1.100/api/motor/open"
    method: POST
    headers:
      Authorization: "Bearer ww_your_token_here"

Home Assistant Integration

Q: Device not showing in HA?

A: Troubleshooting steps:

1. Check MQTT integration:

Configuration → Integrations → MQTT
Should show "Connected"

2. Enable discovery:

# Device settings
MQTT Discovery: Enabled
Discovery Prefix: homeassistant

3. Check discovery messages:

# Subscribe to discovery topic
mosquitto_sub -h 192.168.1.50 -t homeassistant/# -v

4. Restart HA:

Developer Tools → Restart

5. Manual configuration: See Software Setup for manual MQTT config.

Q: HA showing device as unavailable?

A: Check availability tracking:

1. Verify LWT configured:

# Device MQTT settings
LWT Enabled: Yes
LWT Topic: motorwala/living-room/availability
LWT Payload: offline

2. Check HA config:

cover:
  - platform: mqtt
    availability_topic: "motorwala/living-room/availability"
    payload_available: "online"
    payload_not_available: "offline"

3. Device actually online?

# Ping device
ping 192.168.1.100

# Check MQTT connection
mosquitto_sub -h 192.168.1.50 \
  -t motorwala/living-room/availability

Q: State updates delayed in HA?

A: Common causes:

1. Using REST instead of MQTT:

REST polls every scan_interval
MQTT is instant
Switch to MQTT for real-time

2. MQTT QoS too high:

# Lower QoS for faster updates
state_topic: "motorwala/living-room/state"
qos: 0  # Instead of 1 or 2

3. HA recorder lag:

Large history database
Slow hardware
Consider excluding sensors

4. Network latency:

Check WiFi signal
Test ping times
Consider WiFi upgrade

Q: How do I create HA template sensors?

A: Examples:

Position percentage:

sensor:
  - platform: template
    sensors:
      blinds_position_percent:
        friendly_name: "Blinds Position"
        unit_of_measurement: "%"
        value_template: "{{ state_attr('cover.living_room_blinds', 'current_position') }}"

Battery level (if added):

sensor:
  - platform: mqtt
    name: "MotorWala Battery"
    state_topic: "motorwala/living-room/battery"
    unit_of_measurement: "%"
    device_class: battery

Derived state:

binary_sensor:
  - platform: template
    sensors:
      blinds_moving:
        friendly_name: "Blinds Moving"
        value_template: >
          {{ states('cover.living_room_blinds') in ['opening', 'closing'] }}

MotorWala Technical

Q: Position accuracy specifications?

A: Accuracy depends on calibration:

After calibration:

Position error: ±2-5%
Repeatability: ±1-3%
Drift per day: <1% (with good mechanics)

Factors affecting accuracy:

Mechanical slippage
Motor type
Travel distance
Speed setting
Environmental factors

Improve accuracy:

Use quality motors
Tight mechanical coupling
Regular recalibration
Lower speed setting

Q: Maximum motor current?

A: Specifications:

Continuous:

3A maximum
2.5A recommended
Heat dissipation required >2A

Peak (startup):

5A for <1 second
Inrush current handling

If motor exceeds limits:

Use external motor driver
Relay to control larger motor
Upgrade power supply

Q: Motor speed control range?

A: Speed settings:

Range: 10-100

10 = ~10% PWM duty cycle
100 = 100% PWM (full speed)

Practical limits:

Minimum: 20-30 (motor dependent)
Below minimum: May not start
Maximum: 100 (full motor voltage)

PWM frequency: 20 kHz (inaudible)

Q: Can I control motor direction in automation?

A: Yes, two ways:

Method 1: Swap in settings:

Settings → Motor → Direction: Reversed

Method 2: Reverse in automation:

# "Close" when you want to "open"
automation:
  - trigger: ...
    action:
      - service: cover.close_cover  # Actually opens (if reversed)

Method 3: Swap wires physically

Q: Position lost after power cycle?

A: Position storage:

Saved to flash:

Last known position
Calibration data
Travel time

On boot:

Restores saved position
May be inaccurate if moved manually
Run calibration if uncertain

To reset position:

curl -X POST http://192.168.1.100/api/motor/calibrate

RelayWala Technical

Q: Relay specifications?

A: Each channel:

Contact rating:

10A @ 250V AC
10A @ 30V DC
Resistive load

Type: SPDT (Single Pole Double Throw)

COM (Common)
NO (Normally Open)
NC (Normally Closed)

Isolation: Optical isolation

Switching:

Mechanical relay (not solid state)
Audible click when switching
~10ms switching time

Q: Inductive load handling?

A: Inductive loads (motors, solenoids) need protection:

Problem: Back-EMF can damage relay contacts

Solution 1: Snubber circuit

Across relay contacts:
- 0.1µF capacitor in series with 100Ω resistor (AC)
- Flyback diode (DC)

Solution 2: Use contactor

RelayWala controls contactor coil
Contactor switches inductive load
Better for heavy motors

Q: Relay clicking but not switching?

A: Diagnosis:

1. Measure contacts:

# With multimeter
# Relay OFF: COM to NO = open circuit
# Relay ON: COM to NO = short circuit (<1Ω)

2. Check wiring:

Verify COM, NO, NC connections
Tighten terminal screws
Inspect for corrosion

3. Test with low voltage:

Use 12V DC to test
Ensures relay working
Then test with actual load

4. Contact wear:

Relays have finite life
Replace relay board if worn
Typical life: 100,000 cycles

Q: Can I use for low voltage DC switching?

A: Yes, excellent for DC:

DC ratings:

Up to 30V DC
10A maximum
Works well with 12V/24V

Common uses:

LED strips (12V/24V)
Door locks (12V)
Pumps (12V/24V)
Motors (low current)

Q: Multiple relays at once?

A: Yes, but consider:

Power consumption:

Each relay: ~70mA
All 4 on: ~280mA
Ensure power supply adequate

Inrush current:

All switching simultaneously
May cause voltage dip
Stagger switching if issue

Interlock mode:

Prevents conflicting states
Use for reversible motors
Safety feature

Firmware & Updates

Q: How do I check firmware version?

A: Multiple methods:

Web interface:

Settings → System → About

API:

curl http://192.168.1.100/api/status | jq '.version'

Serial console:

screen /dev/ttyUSB0 115200
# Version printed on boot

Q: Update failed, device not booting?

A: Recovery steps:

1. Check power:

Disconnect for 30 seconds
Reconnect and wait 2 minutes

2. Serial recovery:

# Download firmware
wget https://github.com/walaworks/firmware/releases/latest/firmware.bin

# Flash via USB
esptool.py --port /dev/ttyUSB0 write_flash 0x10000 firmware.bin

3. Factory reset:

Hold reset button 30 seconds
Device returns to factory state
Restore configuration backup

Q: Can I downgrade firmware?

A: Yes, but caution:

1. Backup first:

curl http://192.168.1.100/api/config/export > backup.json

2. Download old firmware:

# From GitHub releases
https://github.com/walaworks/firmware/releases/

3. Upload via settings:

Settings → Firmware → Manual Upload

4. Restore config:

curl -X POST http://192.168.1.100/api/config/import \
  -d @backup.json

Note: Config may not be compatible with older firmware.

Q: Beta firmware available?

A: Yes, for early adopters:

Access:

GitHub releases (pre-release)
Community forum beta section
Developer Discord channel

Risks:

May have bugs
Config changes possible
Backup before flashing

Benefits:

Early access to features
Help improve product
Community recognition

Performance & Optimization

Q: Device response time?

A: Typical latency:

Command to action:

HTTP API: 50-100ms
MQTT: 20-50ms
WebSocket: 10-30ms

State update:

MQTT publish: <10ms
HA receives: 20-50ms (total)

Factors:

Network quality
WiFi signal strength
Broker performance
Device load

Q: How many MQTT messages per second?

A: Capacity:

Device can handle:

10 commands/sec sustained
20 commands/sec burst
Higher rates may be dropped

Typical usage:

1-2 messages/sec normal
5-10 messages/sec busy

Optimization:

Batch commands if possible
Use appropriate QoS
Monitor message rate

Q: Memory usage?

A: ESP32 resources:

Total RAM: 320 KB Typical usage:

Idle: 40-60 KB free
Active: 20-40 KB free
Critical: <10 KB

Check memory:

curl http://192.168.1.100/api/system/metrics | jq '.memory'

If low memory:

Disable unused features
Reduce logging
Factory reset

Q: CPU usage high?

A: Normal usage:

Idle: 5-15% Active: 20-40% High load: 50-70%

Causes of high CPU:

Rapid motor movements
High MQTT message rate
Multiple WebSocket clients
Debug logging enabled

Solutions:

Reduce polling frequency
Lower log level
Limit WebSocket connections

Still Need Help?

If your question isn't answered here:

Check main docs: Documentation Home
Search community: community.walaworks.com
GitHub issues: Technical bugs and feature requests
Email support: support@walaworks.com

Include in support requests:

Device model and firmware version
Problem description
Steps to reproduce
Logs and configuration (if relevant)

Technical support: support@walaworks.com | Community: community.walaworks.com