Viper 4105V install, 3rd Gen Dodge Ram 1500

So living in a northern climate makes you appreciate any little thing that can keep you from unnecessarily going outside during winter.  Hence, a remote start.

I recently bought a 2003 Ram 1500 quad cab SLT 4x4 that luckily came with a topper but no keyless and no remote start.  I still think its odd beacause my old 2000 Sierra came with keyless, auto-headlights and no distributor cap/rotor. (That's a whole 'nother gripe)

Anyway I picked up a Viper 4105V Remote Start and Keyless system this past week at a steal! Too good to pass up.  No unbeknownst to me is that Viper is HORRIBLE at instructions. Their systems are sold to consumers but you are expected to get it professionally installed.  They will not give you more detailed instructions for the actual install than a pinout and a very short descriptor of what each wire does.  It's up to you to obtain a wiring diagram for your vehicle and translate their descriptions to match the wiring in your vehicle.

Anyway after much trial, some error and a few wise tidbits from 12volt.com I completed the install in about 6 hours.  (With food and beer breaks).

So below is an ugly table of my findings, hope it helps someone. Oh BTW my truck does not have a transponder key, if yours does you will have to get a bypass module.


pin number - color - description - ram wire


Pri Harness

1 Light green black - 200ma factory alarm disarm - NOT USED

2 Green/white - 200ma factory alarm arm - NOT USED

3 yellow - ignition out - To Heavy 6 NOT USED

4 white/blue - activation output - NOT USED

5 orange - 500ma ground when locked - NOT USED

6 brown - 200ma horn output - black/red steering column

7 red/white - trunk release - NOT USED  (Might use this for a tailgate lock)

8 black - ground

**9 white - light flash - purple/yellow @ headlight switch with relay and 330 ohm resistor


Remote start harness

1 black/white - parking brake - ground

2 purple/white - tach - injector or coil wire Any wire other than teh green wire on the coil

3 brown - brake shutdown - white/tan above brake pedal

4 gray - hood pin - ground when hood shut

5 blue/white - 200ma rear defogger - NOT USED


Heavy Gauge Relay Harness

1 red - 12vdc input - red/white steering column

2 pink/white - Second ign/accessory out NOT USED

3 red - 12vdc input - red/white steering column

4 orange - accessory input - orange steering column NOT USED

5 purple - starter output - yellow steering column

6 pink - ignition 1 input - steering column NOT USED


Door Lock*

1 blue - -200ma unlock out - blue driver kick panel

2 empty

3 green -200ma lock out - tan/pink driver kick panel


Satellite Harness not used

D2D (I dont even know what this is) likely unused

Bitwriter harness not used

* used 2 x relays, unlock needs 330ohm resistor, lock needs 820ohm. (I used 330 and 1k and it works) http://diagrams.marktoonen.nl/DOWNLOADS/26500_RAM-FULL-SIZE-PICKUP-_DODGE%20RAM%201%20WIRE%20JBS%20UNITS.pdf
** http://diagrams.marktoonen.nl/DOWNLOADS/17044_RAM-FULL-SIZE-PICKUP-_CHRYSLER%20PARKING%20LIGHT%20DIAGRAM.pdf


UPDATE:


I sent an email to Viper's customer support, I had heard they would not help you unless you are an authorized dealer. That's rumor turns out to be true. If you won't offer support then why sell on Amazon??



Type your response ABOVE THIS LINE to reply


Benjamin Hart

Subject: Viper.com - Customer Feedback/Question

DEC 27, 2016 | 03:17PM PST
Ashley replied:

Good Afternoon,

Thank you for contacting Directed Electronics Consumer Support. Unfortunately we only provide installation and troubleshooting support on this product if you are an authorized dealer. Please take the vehicle back to an authorized dealer. You can go to Directed.com and use the dealer locator tool to find your nearest authorized dealer.

This policy is in place to ensure that Directed Electronics is not held liable for damage caused by improper installation of this particular product.


Directed Electronics Consumer Support Team

1-800-876-0800


Best Regards,
Ashley

DEC 25, 2016 | 02:57PM PST
Original message
Benjamin wrote:

Name: Ben
Email Address: emails_address@me.com
Phone Number: 123-555-1212

Attention to Directed Department: Customer Service

Feedback/Question: I just bought a 4105V and I have a few questions. A. What is the purpose of the Satellite harness? B. What is the purpose of the D2D harness? C. Do you produce an actual Install guide, not vehicle specific, but the Quick Reference Install Guide kinda sucks. It's helpful but not a ton for self-installers. Thanks!

This email may contain confidential and/or privileged information. It is intended only for the person or persons to whom it is addressed. Any unauthorized review, use, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email or telephone and destroy all copies of the original message.



This message was sent to email_address@me.com in reference to Case #: 129381.

Last reply.. warranty null and void.

Subject: Viper.com - Customer Feedback/Question

---

DEC 28, 2016  |  04:04PM PST 
Ashley replied:

Hello,

We do not sell our products to anyone but authorized dealers. If you bought this module from Ebay, Amazon ect., unfortunately, the device's limited warranty is immediately voided. As stated on our website, we only advise professional installation from authorized dealers as they are specially trained on how to install our devices. We are unable to guide an individual through installation due to liability issues. Please proceed to an authorized dealer.

Please go to the link below and you will be able to find an authorized dealer in your area.

http://www.directed.com/Contact/WhereToBuy.aspx

If you have any other questions, please feel free to call or email.

Thank you for your patience,
Directed Electronics Consumer Support Team
1-800-876-0800

Best Regards,

Ashley

If you care about a warranty, DO NOT BUY VIPER PRODUCTS and install yourself.

Linux One-Liner in YAML (Ansible format)

So the linux config one-liner I posted yesterday.  Here it is in a workable Ansible playbook format:

---
- hosts: all
  name: Run the massive config one-liner
  become: yes
  tasks:
  - shell: set -x; history ; last  -n 666 -a -d -x -F ; who ; uptime ; uptime -p ; cat /etc/red-hat/release ; uname -a ; iptables-save ; netstat -tunap ; ps aufx ; yum list installed ; chkconfig --list ; chkconfig --list | grep on ; cat /etc/passwd ; cat /etc/group ; cat /etc/ssh/ssh_config ; cat /etc/ssh/sshd_config ; cat /root/.ssh/config ; cat /root/.ssh/authorized_keys ; cat /root/.ssh/known_hosts ; cat /home/*/.ssh/known_hosts >> /root/"$HOSTNAME"_"$USER"_`date +%F`.log 2>&1

Linux One-Liner Config Backup

So here at $newjob we've ran into Linux server, in all three environments, with huge uptimes and little documentation.  My co-workers already had one such beast get a forced reboot and things did not work correctly when it came back up.
So this morning I lucked into a nice one-liner that will pull all the infos.  Seriously it's damn good.  Props go out to /u/WOLF3D_exe

history >> "$HOSTNAME"_"$USER"_`date +%F`.log && last  -n 666 -a -d -x -F >> "$HOSTNAME"_"$USER"_`date +%F`.log && who >> "$HOSTNAME"_"$USER"_`date +%F`.log && uptime  >> "$HOSTNAME"_"$USER"_`date +%F`.log && uptime -p  >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /etc/redhat-release  >> "$HOSTNAME"_"$USER"_`date +%F`.log && uname -a >> "$HOSTNAME"_"$USER"_`date +%F`.log && iptables-save  >> "$HOSTNAME"_"$USER"_`date +%F`.log && netstat -tunap >> "$HOSTNAME"_"$USER"_`date +%F`.log && ps aufx >> "$HOSTNAME"_"$USER"_`date +%F`.log && yum list installed >>  "$HOSTNAME"_"$USER"_`date +%F`.log && chkconfig --list >> "$HOSTNAME"_"$USER"_`date +%F`.log  && chkconfig --list |grep on >> "$HOSTNAME"_"$USER"_`date +%F`.log  && >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /etc/passwd >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /etc/group >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /etc/ssh/ssh_config >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /etc/ssh/sshd_config >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /root/.ssh/config >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /root/.ssh/authorized_keys >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /root/.ssh/known_hosts >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /home/*/.ssh/config >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /home/*/.ssh/authorized_keys >> "$HOSTNAME"_"$USER"_`date +%F`.log && cat /home/*/.ssh/known_hosts >> "$HOSTNAME"_"$USER"_`date +%F`.log

Ansible Tower.. Not Worth The Effort.

So a month ago I decided to try out Tower on a trial basis.  I was plagued with issues from the start.  First off the installer would bomb out.. long story short due to missing values in teh Inventory file.  Why were they missing?  Because the documentation failed to explain in great enough detail that you had to specify 'localhost' instead the actual hostname and that you had to specify a pg port of 5342 AND that the installer looks for a separate database by default.  No prompts or anything.
Then once I finally got it fully installed and working.. a day later it'd fail to authenticate 'admin' in the web interface.  You can change the admin accounts password via the command line however that even does not work.  The only fix I found was a reinstall.. which yeah, there goes your config.

Anyway Red Hat can kiss it for now.  Maybe when it goes Open Source next year it'll be more stable.

Ansible Playbooks - Full YML Outline

So I stumbled across a YML playbook that puportedly outlines every single option you can handle inside a PB.

https://gist.github.com/marktheunissen/2979474

---
	# ^^^ YAML documents must begin with the document separator "---"
	#
	#### Example docblock, I like to put a descriptive comment at the top of my
	#### playbooks.
	#
	# Overview: Playbook to bootstrap a new host for configuration management.
	# Applies to: production
	# Description:
	# Ensures that a host is configured for management with Ansible.
	#
	###########
	#
	#
	# Note:
	# YAML, like Python, cares about whitespace. Indent consistently throughout.
	# Be aware! Unlike Python, YAML refuses to allow the tab character for
	# indentation, so always use spaces.
	#
	# Two-space indents feel comfortable to me, but do whatever you like.
	# vim:ff=unix ts=2 sw=2 ai expandtab
	#
	# If you're new to YAML, keep in mind that YAML documents, like XML
	# documents, represent a tree-like structure of nodes and text. More
	# familiar with JSON? Think of YAML as a strict and more flexible JSON
	# with fewer significant characters (e.g., :, "", {}, [])
	#
	# The curious may read more about YAML at:
	# http://www.yaml.org/spec/1.2/spec.html
	#
	###
	# Notice the minus on the line below -- this starts the playbook's record
	# in the YAML document. Only one playbook is allowed per YAML file. Indent
	# the body of the playbook.
	-
	hosts: all
	###########
	# Playbook attribute: hosts
	# Required: yes
	# Description:
	# The name of a host or group of hosts that this playbook should apply to.
	#
	## Example values:
	# hosts: all -- applies to all hosts
	# hosts: hostname -- apply ONLY to the host 'hostname'
	# hosts: groupname -- apply to all hosts in groupname
	# hosts: group1,group2 -- apply to hosts in group1 & group2
	# hosts: group1,host1 -- mix and match hosts
	# hosts: *.mars.nasa.gov wildcard matches work as expected
	#
	## Using a variable value for 'hosts'
	#
	# You can, in fact, set hosts to a variable, for example:
	#
	# hosts: $groups -- apply to all hosts specified in the variable $groups
	#
	# This is handy for testing playbooks, running the same playbook against a
	# staging environment before running it against production, occasional
	# maintenance tasks, and other cases where you want to run the playbook
	# against just a few systems rather than a whole group.
	#
	# If you set hosts as shown above, then you can specify which hosts to
	# apply the playbook to on each run as so:
	#
	# ansible-playbook playbook.yml --extra-vars="groups=staging"
	#
	# Use --extra-vars to set $groups to any combination of groups, hostnames,
	# or wildcards just like the examples in the previous section.
	#
	sudo: True
	###########
	# Playbook attribute: sudo
	# Default: False
	# Required: no
	# Description:
	# If True, always use sudo to run this playbook, just like passing the
	# --sudo (or -s) flag to ansible or ansible-playbook.
	user: remoteuser
	###########
	# Playbook attribute: user
	# Default: "root'
	# Required: no
	# Description
	# Remote user to execute the playbook as
	###########
	# Playbook attribute: vars
	# Default: none
	# Required: no
	# Description:
	# Set configuration variables passed to templates & included playbooks
	# and handlers. See below for examples.
	vars:
	color: brown
	web:
	memcache: 192.168.1.2
	httpd: apache
	# Tree-like structures work as expected, but be careful to surround
	# the variable name with ${} when using.
	#
	# For this example, ${web.memcache} and ${web.apache} are both usable
	# variables.
	########
	# The following works in Ansible 0.5 and later, and will set $config_path
	# "/etc/ntpd.conf" as expected.
	#
	# In older versions, $config_path will be set to the string "/etc/$config"
	#
	config: ntpd.conf
	config_path: /etc/$config
	########
	# Variables can be set conditionally. This is actually a tiny snippet
	# of Python that will get filled in and evaluated during playbook execution.
	# This expressioun should always evaluate to True or False.
	#
	# In this playbook, this will always evaluate to False, because 'color'
	# is set to 'brown' above.
	#
	# When ansible interprets the following, it will first expand $color to
	# 'brown' and then evaluate 'brown' == 'blue' as a Python expression.
	is_color_blue: "'$color' == 'blue'"
	#####
	# Builtin Variables
	#
	# Everything that the 'setup' module provides can be used in the
	# vars section. Ansible native, Facter, and Ohai facts can all be
	# used.
	#
	# Run the setup module to see what else you can use:
	# ansible -m setup -i /path/to/hosts.ini host1
	main_vhost: ${ansible_fqdn}
	public_ip: ${ansible_eth0.ipv4.address}
	# vars_files is better suited for distro-specific settings, however...
	is_ubuntu: "'${ansible_distribution}' == 'ubuntu'"
	##########
	# Playbook attribute: vars_files
	# Required: no
	# Description:
	# Specifies a list of YAML files to load variables from.
	#
	# Always evaluated after the 'vars' section, no matter which section
	# occurs first in the playbook. Examples are below.
	#
	# Example YAML for a file to be included by vars_files:
	# ---
	# monitored_by: phobos.mars.nasa.gov
	# fish_sticks: "good with custard"
	# # (END OF DOCUMENT)
	#
	# A 'vars' YAML file represents a list of variables. Don't use playbook
	# YAML for a 'vars' file.
	#
	# Remove the indentation & comments of course, the '---' should be at
	# the left margin in the variables file.
	#
	vars_files:
	# Include a file from this absolute path
	- /srv/ansible/vars/vars_file.yml
	# Include a file from a path relative to this playbook
	- vars/vars_file.yml
	# By the way, variables set in 'vars' are available here.
	- vars/$hostname.yml
	# It's also possible to pass an array of files, in which case
	# Ansible will loop over the array and include the first file that
	# exists. If none exist, ansible-playbook will halt with an error.
	#
	# An excellent way to handle platform-specific differences.
	- [ vars/$platform.yml, vars/default.yml ]
	# Files in vars_files process in order, so later files can
	# provide more specific configuration:
	- [ vars/$host.yml ]
	# Hey, but if you're doing host-specific variable files, you might
	# consider setting the variable for a group in your hosts.ini and
	# adding your host to that group. Just a thought.
	##########
	# Playbook attribute: vars_prompt
	# Required: no
	# Description:
	# A list of variables that must be manually input each time this playbook
	# runs. Used for sensitive data and also things like release numbers that
	# vary on each deployment. Ansible always prompts for this value, even
	# if it's passed in through the inventory or --extra-vars.
	#
	# The input won't be echoed back to the terminal. Ansible will always
	# prompt for the variables in vars_prompt, even if they're passed in via
	# --extra-vars or group variables.
	#
	# TODO: I think that the value is supposed to show as a prompt but this
	# doesn't work in the latest devel
	#
	vars_prompt:
	passphrase: "Please enter the passphrase for the SSL certificate"
	# Not sensitive, but something that should vary on each playbook run.
	release_version: "Please enter a release tag"
	##########
	# Playbook attribute: tasks
	# Required: yes
	# Description:
	# A list of tasks to perform in this playbook.
	tasks:
	##########
	# The simplest task
	# Each task must have a name & action.
	- name: Check that the server's alive
	action: ping
	##########
	# Ansible modules do the work!
	- name: Enforce permissions on /tmp/secret
	action: file path=/tmp/secret mode=0600 owner=root group=root
	#
	# Format 'action' like above:
	# <modulename> <module parameters>
	#
	# Test your parameters using:
	# ansible -m <module> -a "<module parameters>"
	#
	# Documentation for the stock modules:
	# http://ansible.github.com/modules.html
	##########
	# Use variables in the task!
	#
	# Variables expand in both name and action
	- name: Paint the server $color
	action: command echo $color
	##########
	# Trigger handlers when things change!
	#
	# Ansible detects when an action changes something. For example, the
	# file permissions change, a file's content changed, a package was
	# just installed (or removed), a user was created (or removed). When
	# a change is detected, Ansible can optionally notify one or more
	# Handlers. Handlers can take any action that a Task can. Most
	# commonly they are used to restart a service when its configuration
	# changes. See "Handlers" below for more about handlers.
	#
	# Handlers are called by their name, which is very human friendly.
	# This will call the "Restart Apache" handler whenever 'copy' alters
	# the remote httpd.conf.
	- name: Update the Apache config
	action: copy src=httpd.conf dest=/etc/httpd/httpd.conf
	notify: Restart Apache
	# Here's how to specify more than one handler
	- name: Update our app's configuration
	action: copy src=myapp.conf dest=/etc/myapp/production.conf
	notify:
	- Restart Apache
	- Restart Redis
	##########
	# Include tasks from another file!
	#
	# Ansible can include a list of tasks from another file. The included file
	# must represent a list of tasks, which is different than a playbook.
	#
	# Task list format:
	# ---
	# - name: create user
	# action: user name=$user color=$color
	#
	# - name: add user to group
	# action: user name=$user groups=$group append=true
	# # (END OF DOCUMENT)
	#
	# A 'tasks' YAML file represents a list of tasks. Don't use playbook
	# YAML for a 'tasks' file.
	#
	# Remove the indentation & comments of course, the '---' should be at
	# the left margin in the variables file.
	# In this example $user will be 'sklar'
	# and $color will be 'red' inside new_user.yml
	- include: tasks/new_user.yml user=sklar color=red
	# In this example $user will be 'mosh'
	# and $color will be 'mauve' inside new_user.yml
	- include: tasks/new_user.yml user=mosh color=mauve
	# Variables expand before the include is evaluated:
	- include: tasks/new_user.yml user=chris color=$color
	##########
	# Run a task on each thing in a list!
	#
	# Ansible provides a simple loop facility. If 'with_items' is provided for
	# a task, then the task will be run once for each item in the 'with_items'
	# list. $item changes each time through the loop.
	- name: Create a file named $item in /tmp
	action: command touch /tmp/$item
	with_items:
	- tangerine
	- lemon
	##########
	# Choose between files or templates!
	#
	# Sometimes you want to choose between local files depending on the
	# value of the variable. first_available_file checks for each file
	# and, if the file exists calls the action with $item={filename}.
	#
	# Mostly useful for 'template' and 'copy' actions. Only examines local
	# files.
	#
	- name: Template a file
	action: template src=$item dest=/etc/myapp/foo.conf
	first_available_file:
	# ansible_distribution will be "ubuntu", "debian", "rhel5", etc.
	- templates/myapp/${ansible_distribution}.conf
	# If we couldn't find a distribution-specific file, use default.conf:
	- templates/myapp/default.conf
	##########
	# Conditionally execute tasks!
	#
	# Sometimes you only want to run an action when a under certain conditions.
	# Ansible will 'only_if' as a Python expression and will only run the
	# action when the expression evaluates to True.
	#
	# If you're trying to run an task only when a value changes,
	# consider rewriting the task as a handler and using 'notify' (see below).
	#
	- name: "shutdown all ubuntu"
	action: command /sbin/shutdown -t now
	only_if: "$is_ubuntu"
	- name: "shutdown the government"
	action: command /sbin/shutdown -t now
	only_if: "'$ansible_hostname' == 'the_government'"
	##########
	# Notify handlers when things change!
	#
	# Each task can optionally have one or more handlers that get called
	# when the task changes something -- creates a user, updates a file,
	# etc.
	#
	# Handlers have human-readable names and are defined in the 'handlers'
	# section of a playbook. See below for the definitions of 'Restart nginx'
	# and 'Restart application'
	- name: update nginx config
	action: file src=nginx.conf dest=/etc/nginx/nginx.conf
	notify: Restart nginx
	- name: roll out new code
	action: git repo=git://codeserver/myapp.git dest=/srv/myapp version=HEAD branch=release
	notify:
	- Restart nginx
	- Restart application
	##########
	# Run things as other users!
	#
	# Each task has an optional 'user' and 'sudo' flag to indicate which
	# user a task should run as and whether or not to use 'sudo' to switch
	# to that user.
	- name: dump all postgres databases
	action: pg_dumpall -w -f /tmp/backup.psql
	user: postgres
	sudo: False
	##########
	# Run things locally!
	#
	# Each task also has a 'connection' setting to control whether a local
	# or remote connection is used. The only valid options now are 'local'
	# or 'paramiko'. 'paramiko' is assumed by the command line tools.
	#
	# This can also be set at the top level of the playbook.
	- name: create tempfile
	action: dd if=/dev/urandom of=/tmp/random.txt count=100
	connection: local
	##########
	# Playbook attribute: handlers
	# Required: no
	# Description:
	# Handlers are tasks that run when another task has changed something.
	# See above for examples. The format is exactly the same as for tasks.
	# Note that if multiple tasks notify the same handler in a playbook run
	# that handler will only run once.
	#
	# Handlers are referred to by name. They will be run in the order declared
	# in the playbook. For example: if a task were to notify the
	# handlers in reverse order like so:
	#
	# - task: touch a file
	# action: file name=/tmp/lock.txt
	# notify:
	# - Restart application
	# - Restart nginx
	#
	# The "Restart nginx" handler will still run before the "Restart
	# application" handler because it is declared first in this playbook.
	handlers:
	- name: Restart nginx
	action: service name=nginx state=restarted
	# Any module can be used for the handler action
	- name: Restart application
	action: command /srv/myapp/restart.sh
	# It's also possible to include handlers from another file. Structure is
	# the same as a tasks file, see the tasks section above for an example.
	- include: handlers/site.yml